Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

On 1/5/16 11:38 PM, Will Senn wrote:



On 1/5/16 7:14 PM, Paul Koning wrote:

On Jan 5, 2016, at 5:07 PM, Will Senn  wrote:

All,

The simulated paper tape device is very handy to copy text around 
between a host and simulated environment. My question for the group 
is, does RSTS/E 10.1-L support the paper tape device? The 
documentation is sketchy about it but does make a rare reference to 
PP: and PR: (help for SYSTAT for example), but it wasn't a question 
during sysgen and I can't figure out how to copy files to it. In 
RT-11, it's as simple as copy whatever PC: or copy PC: whatever...
Yes, RSTS does support those.  I don't know why Sysgen doesn't ask.  
It doesn't ask about DECtape, either.  Perhaps they are no longer 
officially supported, but the software should be there and it should 
work.


After running sysgen but before running the resulting sysgen.com 
script, edit config.mac.  Look for the line that mentions PR11 and 
change the 0 to 1, then the next line (PP11) also 0 change to 1.  
While you're there, if you want DECtape, change TC11 (just above 
PR11) to be the number of DECtape drives.  Typically that's an even 
number because a TU56 has two DECtape drives in it.


paul

I followed the steps Paul provided with Christian's clarification and 
am now able to copy files to the paper tape punch device PP:...


$ copy instal.log pp:
[File INSTAL.LOG copied to PP:[1,2]]

The ptp.txt file on the host now contains the contents of instal.log 
from rsts/e. Woohoo, half way there...


but copying files from PR: doesn't seem to work:
$ copy pr: hello.mac
?Device hung or write locked - file PR:??.???

I tried PR0: as well, same result. Is the copy command different from 
what I typed? or do I need to enable read on the PR device somehow?


Thanks,

Will


Update. If the copy is the first thing after attaching ptr in simh, it 
works:

$ copy PR: HELLO.MAC
[File PR:??.??? copied to [1,2]HELLO .MAC]
$ macro/rt11 hello/list
$ link/rt11 hello/map
$ run hello
HELLO, WORLD

Any subsequent use of PR fails (which makes sense, really, after all, 
the PTR should be positioned after the read):

?Device hung or write locked - file PR:??.???

until ptr is attached again. I'm not sure how I missed this the first go 
around, I didn't think it ever succeeded, but I've verified that it 
seems to always works after an attach. Is there a 
reset/rewind/reposition device function that will work with PR in RSTS? 
I can work around it with reattachment in SIMH if all else fails.


Thanks,

Will



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Mark Pizzolato]

On Tuesday, January 5, 2016 at 9:08 PM, Christian Gauger-Cosgrove wrote:
> On 5 January 2016 at 20:29, Mark Pizzolato  wrote:
> > By the way, I'm looking for folks to test the TU58 device (TDC) on the
> > various
> > PDP11 operating systems.  I've tested it on VMS and things work well.
> >
> RSTS/E supports the DECtape II, I'd test it, but please see my gripe...
> 
> The current implementation of the TDC and DLI devices is not that great.
> With TDC enabled, you can't setup DLI, and vice versa. This is because TDC
> takes the address and vector of the first DL11/DLV11 serial line (because,
> naturally, the TU58 attached to said first serial line), and you can't change 
> the
> address and vector settings on DLI to "shift" it to the next serial line.

This is a bug.  This didn't show up while testing on the VAX since the VAX 
doesn't have DL device support.

The latest code fixes this problem and will now allow up to a total of 16 
TDC controllers and/or DL lines.

Now that you can get beyond your initial configuration steps I'm still looking 
for feedback about any device driver issues that may exist with various PDP11
operating systems when accessing TU58 devices.

Thanks.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

Johnny,

Thanks for the information. Responses inline.

On 1/6/16 8:44 AM, Johnny Billquist wrote:
There is no way to software wise reset the paper tape from the OS. The 
paper tape is a physical thing. I real life, you would need to 
actually take the paper tape and "mount" it in the reader, and set the 
reader online. And after that, the tape can be read by software.



I get it... now :), thanks.

As for transferring files to and from your RSTS/E system, you do know 
of KERMIT, right? Telnet into the RSTS/E system, start a kermit server 
there, switch back to your local kermit, and then send/receive files 
to your hearts content.


Ha! Let's just say that I used KERMIT once back in the early 90's and 
have never used it since. I seem to recall something called zmodem that 
was easier to use (at least for the year my wife was in grad school and 
I had to connect to the internet through my DEC Rainbow 100 running DOS 
3.10b and a super fast 300 baud modem to the university's VMS system). 
But then again, it was all ftp and browsers the year after that (and a 
486 with 56K modem, Windows 95, and trumpet tcp I think). I may be old 
enough for vague recollections of bbses and such, but experientially, 
I'm solidly post tcp/ip, post-Mosaic, and post www. Everything old is 
new to me!


When you say, start a kermit server, I don't think there is one already 
on the system. I have to get it on the system somehow first. If there's 
a tape or disk image available that RSTS can use, then it's just a 
matter of installing and running it. I say just, I'm still getting up to 
speed on installing and running programs in RSTS. I'll be working on it...


Other options could be using a disk with the files on it, setting up 
tapes, but also, if simh supports it, possibly using the virtual DOS 
device, that other emulators have, as well as using DECnet.



Does the virtual DOS device work in linux/mac?

As for "using" DECnet... hmm, I'm working on getting DECnet working, the 
install and configuration of sim seem to be reasonable. I just don't 
know what to do with it once it's running. This is my refrain, I'm 
working on it :). The list of items on my "To Understand" list far 
outnumber the "Understood" list. My unfounded belief is that DECnet is 
quite different from modern networking and that it doesn't have a 
toolset that I'm familiar with - no ping, no ssh, no telnet, not even 
rcp or rsh and such so if I get it running. What might a copy from host 
to sim look like? copy HOST:FILE SY:FILE or something similar?


If you have some RSX, RT-11 or VMS system nearby, you can also use 
TCP/IP on those systems, and then transfer using one of the above 
suggested methods to just get the files over to RSTS/E.
I only have simh systems, no real systems. I have RT-11, but I don't 
think it has TCP/IP. I'll be working on it...


Thanks,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Paul Koning]

> On Jan 6, 2016, at 9:44 AM, Johnny Billquist  wrote:
> 
> ...
> As for transferring files to and from your RSTS/E system, you do know of 
> KERMIT, right? Telnet into the RSTS/E system, start a kermit server there, 
> switch back to your local kermit, and then send/receive files to your hearts 
> content.
> 
> Other options could be using a disk with the files on it, setting up tapes, 
> but also, if simh supports it, possibly using the virtual DOS device, that 
> other emulators have, as well as using DECnet.

I'm not sure what a DOS device is.

A couple of options:

1. DECnet.  NFT will use the DAP protocol to do file transfer; if you have a 
compatible DAP implementation at the other end that would work.  DECnet/Linux 
can do this, I believe.

2. Paper tape, as discussed here.

3. Magtape.  DOS format labels are very simple; ANSI isn't much harder.  For 
extra credit, someone could write an implementation of VMS BACKUP -- RSTS can 
read those tapes (with some restrictions) in V9.0 or later.

4. Disk.  Years ago I wrote a program "rstsflx" that can read and write RSTS 
disk images.  It should still be around; if not I should build some new kits 
and supply them to whoever can offer a place for them.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

On 1/6/16 9:08 AM, Will Senn wrote:

Johnny escribe:
As for transferring files to and from your RSTS/E system, you do know 
of KERMIT, right? Telnet into the RSTS/E system, start a kermit 
server there, switch back to your local kermit, and then send/receive 
files to your hearts content.




OK. I'm making progress. I downloaded K11RSX.HEX from 
ftp://kermit.columbia.edu/kermit/b/ along with K11HEX.BAS and using my 
nifty paper tape reader (after running unix2dos on the files) I got them 
on RSTS. I then ran K11HEX.BAS and converted K11RSX.HEX to K11RSX.TSK and:


$ run K11RSX.TSK
Kermit-11 T3.60  Last edit: 21-Mar-89

Check SHOW RELEASE_NOTES for possible incompatabilities
with previous releases of Kermit-11 and other Kermits.
Linked for RSX11M/M+ and P/OS
Kermit-11>

Will you look at that?

On my Mac, I brew install'd c-kermit and now I am able to run Kermit on 
both ends of the connect. Kermit will even do telnet, so I have telnet'd 
to one of the DZ connections successfully.


If you want to share how you actually do a file transfer using the 
amazing kermit, I would appreciate it. Meanwhile, I'm busy reading docs 
and googling to figure it out.


Thanks,

Will

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Johnny Billquist]

On 2016-01-06 15:35, Will Senn wrote:



On 1/5/16 11:38 PM, Will Senn wrote:



On 1/5/16 7:14 PM, Paul Koning wrote:

On Jan 5, 2016, at 5:07 PM, Will Senn  wrote:

All,

The simulated paper tape device is very handy to copy text around
between a host and simulated environment. My question for the group
is, does RSTS/E 10.1-L support the paper tape device? The
documentation is sketchy about it but does make a rare reference to
PP: and PR: (help for SYSTAT for example), but it wasn't a question
during sysgen and I can't figure out how to copy files to it. In
RT-11, it's as simple as copy whatever PC: or copy PC: whatever...

Yes, RSTS does support those.  I don't know why Sysgen doesn't ask.
It doesn't ask about DECtape, either.  Perhaps they are no longer
officially supported, but the software should be there and it should
work.

After running sysgen but before running the resulting sysgen.com
script, edit config.mac.  Look for the line that mentions PR11 and
change the 0 to 1, then the next line (PP11) also 0 change to 1.
While you're there, if you want DECtape, change TC11 (just above
PR11) to be the number of DECtape drives.  Typically that's an even
number because a TU56 has two DECtape drives in it.

paul


I followed the steps Paul provided with Christian's clarification and
am now able to copy files to the paper tape punch device PP:...

$ copy instal.log pp:
[File INSTAL.LOG copied to PP:[1,2]]

The ptp.txt file on the host now contains the contents of instal.log
from rsts/e. Woohoo, half way there...

but copying files from PR: doesn't seem to work:
$ copy pr: hello.mac
?Device hung or write locked - file PR:??.???

I tried PR0: as well, same result. Is the copy command different from
what I typed? or do I need to enable read on the PR device somehow?

Thanks,

Will



Update. If the copy is the first thing after attaching ptr in simh, it
works:
$ copy PR: HELLO.MAC
[File PR:??.??? copied to [1,2]HELLO .MAC]
$ macro/rt11 hello/list
$ link/rt11 hello/map
$ run hello
HELLO, WORLD

Any subsequent use of PR fails (which makes sense, really, after all,
the PTR should be positioned after the read):
?Device hung or write locked - file PR:??.???

until ptr is attached again. I'm not sure how I missed this the first go
around, I didn't think it ever succeeded, but I've verified that it
seems to always works after an attach. Is there a
reset/rewind/reposition device function that will work with PR in RSTS?
I can work around it with reattachment in SIMH if all else fails.


There is no way to software wise reset the paper tape from the OS. The 
paper tape is a physical thing. I real life, you would need to actually 
take the paper tape and "mount" it in the reader, and set the reader 
online. And after that, the tape can be read by software.


As for transferring files to and from your RSTS/E system, you do know of 
KERMIT, right? Telnet into the RSTS/E system, start a kermit server 
there, switch back to your local kermit, and then send/receive files to 
your hearts content.


Other options could be using a disk with the files on it, setting up 
tapes, but also, if simh supports it, possibly using the virtual DOS 
device, that other emulators have, as well as using DECnet.


If you have some RSX, RT-11 or VMS system nearby, you can also use 
TCP/IP on those systems, and then transfer using one of the above 
suggested methods to just get the files over to RSTS/E.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Paul Koning]

> On Jan 6, 2016, at 10:59 AM, Timothe Litt  wrote:
> 
> On 06-Jan-16 10:51, Paul Koning wrote:
>> 4. Disk. Years ago I wrote a program "rstsflx" that can read and write
>> RSTS disk images. It should still be around; if not I should build
>> some new kits and supply them to whoever can offer a place for them. paul
> Please contribute tools to https://githubm.com/simh/simtools  There are
> tools for conversion and file manipulation.  rstsflx would go under
> 'extracters'. 

Will do.

> And if you have docs on on-disk formats, please make sure there's a copy
> on bitsavers in addition to any that you keep with your tool.

They are documented in the RSTS Internals Manual.  I have paper copies but I'm 
not going to let those out of my hands, because I don't want to have them 
disappear.  If someone wants them on bitsavers, go right ahead with your own 
copy.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Johnny Billquist]

On 2016-01-07 01:00, Mark Pizzolato wrote:

On  Wednesday, January 6, 2016 at 2:49 PM, Johnny Billquist wrote:

Other options could be using a disk with the files on it, setting up
tapes, but also, if simh supports it, possibly using the virtual DOS
device, that other emulators have, as well as using DECnet.


Does the virtual DOS device work in linux/mac?


Does the DOS device exist in simh would be the first question...


No such thing is in simh.

It is not clear exactly what or how this would work with the legacy
systems that are around.


Not sure how that matters...


It would be hard to imagine that actually emulating a DOS disk structure
(FAT, NTFS or other) would be useful since then someone would have
to write driver software for each legacy OS to interpret this completely
foreign structure.  The next logical step would be to implement some
'natural' file system that some least common denominator of legacy
Systems could understand.  This might be RT-11 format maybe.


Uh? You are thinking too much.
The device actually have functions to find a specific file, open the 
specific file, read and write byte ranges, and close the file. How the 
host file system looks like, or other semantics, are totally hidden from 
the user of the device. You essentially ask it OPEN("FOO.BAR") and it 
either succeeds or fails. After that, you can read N bytes, write N 
bytes, seek to a specific position, or close the file.
So you just have a DMA address, a byte count, and a command register. 
Not much more. I can dig up my notes on exactly how it works if anyone 
is interested. It was years since I wrote my device driver.


But I don't have time to actually implement this in simh myself at the 
moment.



If someone wants to take on this concept, I'll be open to looking at what
they're thinking.

Meanwhile, the 'crude' way to exchange data on most simulators can
actually be done with cut and paste in console or telnet sessions.


Indeed. That also works. But it is really problematic when copying data 
into the simulator, since this goes through the OS terminal driver, 
which have limitations. Pasting in data often leads to data loss in my 
experience. But copying out works fine.



Real files can move over the network (possibly with a couple of hops)
from modern systems via tcp (FTP) into VMS or RSX (thanks Johnny)
systems which can then pass them via DECnet to RSTS.


Yes. DECnet is a viable option.

But I still maintain that KERMIT is really the easiest solution to start 
with.


Johnny

--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Rich Alderson]

> From: Mark Pizzolato 
> Date: Wed, 6 Jan 2016 16:00:19 -0800

> Meanwhile, the 'crude' way to exchange data on most simulators can 
> actually be done with cut and paste in console or telnet sessions.

While I do use c for command lines from time to time, I've never found it to
be satisfactory for file transfer.  For that, I wrote a set of programs for
TOPS-20 to create or disassemble .tap (in klh10 terms, .tps) files.  (Well, I
also wrote versions for .tpc files, but I've never had reason to keep them up
to date as I've improved on the .tap variants.)

These have stood me in good stead for TOPS-20, Tops-10, ITS, and WAITS work,
moving data between real media, real systems, image files, and both SimH and
klh10.  I advocate for using tape images for most data transfer, since most of
the emulated minis and mainframes under SimH never had any kind of networking.

On the other hand, I'm one of the three people I know of in the world who still
makes a living programming in PDP-10 assembler.

Rich
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Christian Gauger-Cosgrove]

You take one day trip to the US and suddenly "Reply Explosion"...

Inlined replies/comments to several previous messages in this thread follow:


On 6 January 2016 at 10:51, Paul Koning  wrote:
> I'm not sure what a DOS device is.
>
The E-11 simulator has a special device which allows you to read from
a normal PC file folder, it's the DOS device. I know there's an RT-11
to use it, and the resident RSX-11 expert (Johnny) can say if there's
also a driver for it. I don't think there is a RSTS/E driver; though
as an aside: How difficult would it be to add in a custom device to
RSTS/E? If one wanted to implement said "DOS device" in RSTS would it
be possible?


> 1. DECnet.  NFT will use the DAP protocol to do file transfer; if you have a 
> compatible DAP implementation at the other end that would work.  DECnet/Linux 
> can do this, I believe.
>
If you can find it DEC PATHWORKS apparently still works on Windows XP,
of course you'll need to fire up a VM for it in most cases; and
DECnet/Linux has basically become unsupported.


> 3. Magtape.  DOS format labels are very simple; ANSI isn't much harder.  For 
> extra credit, someone could write an implementation of VMS BACKUP -- RSTS can 
> read those tapes (with some restrictions) in V9.0 or later.
>
May I inquire how to read VMS BACKUP format? Also, by any chance can
RSTS read RSX style BRU format (...isn't RSX-11 BRU format actually
the predecessor/a subset of VMS BACKUP)?


> 4. Disk.  Years ago I wrote a program "rstsflx" that can read and write RSTS 
> disk images.  It should still be around; if not I should build some new kits 
> and supply them to whoever can offer a place for them.
>
You can also use AUXLIB$:FIT within RSTS to read and write RT-11
format media. So you could make an RT-11 formatted disk with John
Wilson's PUTR utility and move files to and from it (with a DOS
emulator like DOSbox because PUTR doesn't play nice on x64 Windows);
it'll work on WXP though. You can also make said RT-11 formatted media
with SIMH running RT-11 as well.


On 6 January 2016 at 11:04, Paul Koning  wrote:
> They are documented in the RSTS Internals Manual.  I have paper copies but 
> I'm not going to let those out of my hands, because I don't want to have them 
> disappear.  If someone wants them on bitsavers, go right ahead with your own 
> copy.
>
Do you have any other of the RSTS/E manuals for V10.1? Or at least a
"high V9.x"? Because there's next to no docs on BitSavers for V10, and
the V9 docs are quite spotty (for example the entirety of Volume 4 is
missing).

And please, please send your one of a kind docs to Al Kossow we really
need this stuff documented. (Would make everyone have a much better
time of "hacking" around with RSTS/E.)


On 6 January 2016 at 11:14, Mark Pizzolato  wrote:
> This is a bug.  This didn't show up while testing on the VAX since the VAX
> doesn't have DL device support.
>
> The latest code fixes this problem and will now allow up to a total of 16
> TDC controllers and/or DL lines.
>
Ahh, cool and thank you very much for the patching. I'll have to
finally become not-lazy and actually setup a Windows build of SIMH
since the current pre-built binaries are from mid-/late-December.


> Now that you can get beyond your initial configuration steps I'm still looking
> for feedback about any device driver issues that may exist with various PDP11
> operating systems when accessing TU58 devices.
>
RSTS being RSTS, we're probably going to see bugs; many bugs.


Speaking of RSTS/E and bugs, it appears that RS03/RS04 simulation is
buggy. I've Pastebin'd a log of what was happening on the console, and
including the DEBUG output for the RS and RHC devices:
 as one can see, while the RS03/RS04
devices seem to respond to utilities like DSKINT and both INIT and
HARDWR can see them (after moving them to an alternate controller
address and vector, because of the RF11... which is also buggy, but
that I think is a RSTS problem). Actually using them within RSTS seems
to be non-functional.

For example, the device was formatted as a PRIVATE disk, and RSTS when
mounting sees it as PUBLIC. (When DSKINT'd from the standalone
utility.) When DSKINT is done "in system" RSTS can't even use the disk
at all. Not shown is the fact that formatting as public, and mounting
as public both result in the RS reporting no directory.


And I think we've gone way off topic, and I should probably start an
issue in the GitHub...


Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Mark Pizzolato]

On  Wednesday, January 6, 2016 at 2:49 PM, Johnny Billquist wrote:
> >> Other options could be using a disk with the files on it, setting up
> >> tapes, but also, if simh supports it, possibly using the virtual DOS
> >> device, that other emulators have, as well as using DECnet.
> >>
> > Does the virtual DOS device work in linux/mac?
> 
> Does the DOS device exist in simh would be the first question...

No such thing is in simh.  

It is not clear exactly what or how this would work with the legacy 
systems that are around.

It would be hard to imagine that actually emulating a DOS disk structure 
(FAT, NTFS or other) would be useful since then someone would have 
to write driver software for each legacy OS to interpret this completely 
foreign structure.  The next logical step would be to implement some
'natural' file system that some least common denominator of legacy
Systems could understand.  This might be RT-11 format maybe.

If someone wants to take on this concept, I'll be open to looking at what 
they're thinking.

Meanwhile, the 'crude' way to exchange data on most simulators can 
actually be done with cut and paste in console or telnet sessions.

Real files can move over the network (possibly with a couple of hops)
from modern systems via tcp (FTP) into VMS or RSX (thanks Johnny) 
systems which can then pass them via DECnet to RSTS.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Johnny Billquist]

On 2016-01-07 01:12, Rich Alderson wrote:

From: Mark Pizzolato 
Date: Wed, 6 Jan 2016 16:00:19 -0800



Meanwhile, the 'crude' way to exchange data on most simulators can
actually be done with cut and paste in console or telnet sessions.


While I do use c for command lines from time to time, I've never found it to
be satisfactory for file transfer.  For that, I wrote a set of programs for
TOPS-20 to create or disassemble .tap (in klh10 terms, .tps) files.  (Well, I
also wrote versions for .tpc files, but I've never had reason to keep them up
to date as I've improved on the .tap variants.)

These have stood me in good stead for TOPS-20, Tops-10, ITS, and WAITS work,
moving data between real media, real systems, image files, and both SimH and
klh10.  I advocate for using tape images for most data transfer, since most of
the emulated minis and mainframes under SimH never had any kind of networking.

On the other hand, I'm one of the three people I know of in the world who still
makes a living programming in PDP-10 assembler.


Wouldn't you like to have a PDP-11 assembler programmer on the paylist 
as well? ;-)


Johnny

--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Larry Baker]

On Jan 6, 2016, at 4:00 PM,  
 wrote:

>> 1. DECnet.  NFT will use the DAP protocol to do file transfer; if you have a 
>> compatible DAP implementation at the other end that would work.  
>> DECnet/Linux can do this, I believe.
>> 
> If you can find it DEC PATHWORKS apparently still works on Windows XP,
> of course you'll need to fire up a VM for it in most cases; and
> DECnet/Linux has basically become unsupported.


Don't dismiss DECnet/Linux as a viable solution.  It's true the DECnet/Linux 
community is small and the main players of long ago are gone.  But, that 
doesn't mean it does not work.

I have been a long time user of DECnet/Linux, mainly on CentOS.  We use it for 
backups over DECnet mostly, and file exchange.  Stand-alone backups work just 
fine.  When the disks on my last CentOS version went belly up, I decided 
instead of a dedicated DECnet NAS, it was a better idea to use our NFS disk 
farms for storage.  I built a couple DECnet/DAP-to-NFS gateways using a Marvell 
SheevaPlug "PlugPC" with a Kirkwood ARM SoC (no FPU).  I am at home at the 
moment, so I cannot tell you what Linux kernel I used.  I haven't checked on 
them in a long time.  As far as I know, they are working just fine.  One is 
used every day to export files from a VAX/VMS 5.5-2 data acquisition system to 
an iMac file server.  That VAX has been running that lab for over 20 years, I 
think—maybe 30.  We used to run Pathworks/Mac on the VAX until Apple removed 
support for their own network file protocol and forced us to come up with an 
alternative.  We run DECnet Phase IV, not Phase V, so we can't do DECnet remote 
file access over TCP/IP.  I've built other SoC appliances using PlugPCs, such 
as Ionics Nimbus.  My last few projects using SoCs have used BeagleBone Blacks. 
 Their processors have FPUs, which makes them more useful.  As I recall, 
Raspberry Pis either did not have an FPU, or priced out more expensive than the 
BeagleBone Black when I last looked at them.  I set them up to be self-hosting 
for development.  Cross-development is a royal pain.

Other discussions here have mentioned using ANSI-labeled tapes.  It is true 
they can be simple.  But, not if you start dealing with records instead of 
blocks.  I briefly looked at the ansitpc tool mentioned earlier in this thread 
at https://github.com/khandy21yo/emutools.  It writes blocks, not records.  It 
also does not properly write the ANSI labels.  Maybe that is what is upsetting 
VMS.  I assume VMS figures it out; if not, you definitely want to mount the 
tape /NOHDR3 on VMS.  The ANSI tape format is an ANSI standard.  I'll grab my 
copy at work tomorrow and send the number.  I assume the VMS documentation also 
cites the ANSI standard they implement.

I just stumbled upon a Unix utility that writes ANSI tapes at 
http://www.math.utah.edu/cgi-bin/man2html.cgi?/usr/local/man/man1/ansitape.1.  
It might be easy to modify it to write TPC format volumes instead of starting 
from scratch.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Larry Baker]

Johnny,

On Jan 6, 2016, at 6:03 PM,  
 wrote:

> Just a short comment. Linux/DECnet do not play right with RSX. The 
> development was all done against VMS, and it would appear to have lots 
> of bugs that were never ironed out. Success against anything except VMS 
> is dicey at best (unfortunately).


Wish I had heard that before we got rid of our RSX-11M-Plus system!

It's true our experience with DECnet/Linux is from VMS.  For the last decades 
we used the RSX system entirely from VMS using DECnet's Task-to-Task feature to 
access custom UNIBUS hardware on a PDP-11/73 with a QNIVERTER.

Do you know if a SIMH RSX system would be able duplicate the errors you are 
talking about?  Do you have any clue whether the problems are in the Linux 
device driver or the applications?  I know there are some configuration hoops 
one has to jump through that seem to change with every new Linux kernel.  I did 
some hacking there to get it working.  But, I never had to hack the 
applications.  That being said, the only one we care about is DAP.

Feel free to drop me a note off-list if you think it is worth pursuing.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Mark Pizzolato]

On Wednesday, January 6, 2016 at 6:21 PM, Johnny Billquist wrote:
> On 2016-01-07 03:08, Mark Pizzolato wrote:
> > On Wednesday, January 6, 2016 at 4:24 PM, Johnny Billquist wrote:
> >> On 2016-01-07 01:00, Mark Pizzolato wrote:
> >>> Meanwhile, the 'crude' way to exchange data on most simulators can
> >>> actually be done with cut and paste in console or telnet sessions.
> >>
> >> Indeed. That also works. But it is really problematic when copying
> >> data into the simulator, since this goes through the OS terminal
> >> driver, which have limitations. Pasting in data often leads to data
> >> loss in my experience. But copying out works fine.
> >
> > Actually, copying data into a simulator with paste has improved vastly
> recently.
> > 10's of Kbytes of data pasted at once without data loss.  Give it a try.
> 
> Uh? Really. How recent do I need it to be then?
> I'm on:
>   PDP-11 simulator V4.0-0 Betagit commit id: e9b312f2

Well, git commit id: e9b312f2 was back on June 6, 2014.  Not too many folks 
would call that recent.  :-)

Recent being in the last month or so.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Timothe Litt]

On 06-Jan-16 20:52, Larry Baker wrote:
> On Jan 6, 2016, at 4:00 PM,  >
>  > wrote:
>
> I just stumbled upon a Unix utility that writes ANSI tapes
> at 
> http://www.math.utah.edu/cgi-bin/man2html.cgi?/usr/local/man/man1/ansitape.1.
>  It might be easy to modify it to write TPC format volumes instead of
> starting from scratch.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov 
>
>
I looked at ansitape a while ago, and at a version that someone hacked
to (almost) write simulator tapes.  Both were very buggy.  My tape
project has a better version in process.  Same round TUIT, but there's
no point in someone else starting over...




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Will Senn]

On 1/6/16 8:27 PM, Mark Pizzolato wrote:

On Wednesday, January 6, 2016 at 6:21 PM, Johnny Billquist wrote:

On 2016-01-07 03:08, Mark Pizzolato wrote:

On Wednesday, January 6, 2016 at 4:24 PM, Johnny Billquist wrote:

On 2016-01-07 01:00, Mark Pizzolato wrote:

Meanwhile, the 'crude' way to exchange data on most simulators can
actually be done with cut and paste in console or telnet sessions.

Indeed. That also works. But it is really problematic when copying
data into the simulator, since this goes through the OS terminal
driver, which have limitations. Pasting in data often leads to data
loss in my experience. But copying out works fine.

Actually, copying data into a simulator with paste has improved vastly

recently.

10's of Kbytes of data pasted at once without data loss.  Give it a try.

Uh? Really. How recent do I need it to be then?
I'm on:
   PDP-11 simulator V4.0-0 Betagit commit id: e9b312f2

Well, git commit id: e9b312f2 was back on June 6, 2014.  Not too many folks 
would call that recent.  :-)

Recent being in the last month or so.

- Mark



The changes Mark made in November were life changing for pasting :).

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] RSTS/E 10.1-L and Paper tape

[Mark Pizzolato]

On Wednesday, January 6, 2016 at 4:24 PM, Johnny Billquist wrote:
> On 2016-01-07 01:00, Mark Pizzolato wrote:
> > Meanwhile, the 'crude' way to exchange data on most simulators can
> > actually be done with cut and paste in console or telnet sessions.
> 
> Indeed. That also works. But it is really problematic when copying data into
> the simulator, since this goes through the OS terminal driver, which have
> limitations. Pasting in data often leads to data loss in my experience. But
> copying out works fine.

Actually, copying data into a simulator with paste has improved vastly recently.
10's of Kbytes of data pasted at once without data loss.  Give it a try.

> But I still maintain that KERMIT is really the easiest solution to start with.

Given that the user can get beyond the chicken and egg problem of getting 
Kermit on the simulated system to start with...

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh