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

Wed Jan 6 17:36:49 EST 2016

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 <paulkoning at comcast.net> 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 <paulkoning at comcast.net> 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 <Mark at infocomm.com> 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:
<http://pastebin.com/L6dHkS48> 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.