Re: [Simh] PDP-15/76

[Andrew Warkentin]

I believe XVM/RSX supports it as well (although it is dependent on
XVM/DOS for booting so the UC15 simulation will have to be working
with XVM/DOS first). Not sure whether the distribution that's
available includes enough to support it (since SIMH didn't support it
I didn't look at that part too closely when I was figuring out how to
install RSX). However, I would be surprised if it requires anything
that's not included in either the RSX or DOS kits.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] The lost disk of the PDP-15

[Richard Cornwell]

  I suspect this might also be to the limited number of XVM15 systems
that were actually sold. I used one at Syracuse University in the early
80's. We had the PDP11 and it talked to the RK05 disk drive. I was told
that there was only about 20 XVM systems sold. We did not have any RP
drives on the system. 

  My KA10 simulator supports RP01/RP02/RP03 disks, do you think there
might be a need to exchange disks between a PDP10 and a PDP15? If so we
should probably use a common format. When I add RP06 support for the
KI10 version I will make sure it is compatible with the KS10 sim so
that packs can be interchanged. 

 We probably could add support for the RP03 to RSX, DOS and Adss, since
 we have source.

Rich

> While I was digging deeper and deeper into the extent PDP-15 sources,
> I found a tantalizing reference: "the RP03 is supported as an RP02."
> This was the first time I'd seen any indication that the PDP-15's RP 
> controller supported the later, double-sized disk. The XVM/MUMPS
> sources (which are, alas, incomplete) also mentioned an RP03. It
> certainly made sense: the RP03 was just an RP02 with twice as many
> cylinders. The RP10-C (with which the RP15 shared a lot of logic)
> supported the RP02 and RP03. But how did the RP15 do it? The XVM
> Systems Manual is useless, for example: it mentions the RP03 but
> shows formats that apply only to the RP02 (8b cylinder address).
> 
> I've spent (wasted) this whole day going through the 1975 revision of 
> the RP15 prints, and I can now specify the very small set of changes 
> that were made in the RP15 to support the RP03:
> 
> 1. The cylinder address register was expanded to 9b.
> 
> 2. An additional interface line was defined from the disk drive ("I
> am an RP03").
> 
> 3. The logic for detecting end of pack/illegal cylinder address was
> made conditional on the RP03 status line:
>   end_of_pack = (RP03? 405: 202);
>   illegal cylinder = cylinder > end_of_pack;
> 
> 4. The load disk address instruction (DPLA) was modified to load a
> ninth cylinder bit from AC:
>  <0:7> = cylinder low order 8b
>  <8:12> = head
>  <13> = cylinder high order bit
>  <14:17> = sector
> 
> 5. The read disk address instruction (DPOA) was modified to read back 
> the ninth cylinder bit, in the same format.
> 
> 6. The read selected unit cylinder instruction (DPOU) was modified to 
> read back nine bits of cylinder and an RP03 indicator:
>  <0> = set if RP03, clear otherwise
>  <9:17> = current cylinder (in normal bit order)
> 
> The RP10-C also had to put the 9th cylinder bit in a spare location.
> 
> So in theory, software could test each disk drive to see if it is an 
> RP03 and react accordingly.
> 
> It would be easy enough to add RP03 support to the RP15, but there's
> no indication (other than MUMPS) that software ever did anything with
> it. The problem was not file structures - DOS-15 used 18b block
> numbers, and an RP03 only had 80,000 blocks. Perhaps the RP03 came
> along too late, or customers were more interested in lower cost
> options like DECtape, the RF15, or the RK15 Unichannel solution.
> 
> /Bob
> 
> P.S. Some other fun things from the MUMPS listing... MUMPS supported
> two LP15 line printers, the second at device address 35. It also
> supported up to 10 instances of a true terminal mux/scanner called
> the DC01EB, about which there is no information beyond the references
> in the MUMPS listing and the Diagnostic Exerciser writeup. MUMPS did
> not support the Unichannel.
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-- 
==
Richard Cornwell
sky...@sky-visions.com
http://sky-visions.com
LinkedIn:   https://www.linkedin.com/in/richard-cornwell-991076107
==

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

[Simh] The lost disk of the PDP-15

[Bob Supnik]

While I was digging deeper and deeper into the extent PDP-15 sources, I 
found a tantalizing reference: "the RP03 is supported as an RP02." This 
was the first time I'd seen any indication that the PDP-15's RP 
controller supported the later, double-sized disk. The XVM/MUMPS sources 
(which are, alas, incomplete) also mentioned an RP03. It certainly made 
sense: the RP03 was just an RP02 with twice as many cylinders. The 
RP10-C (with which the RP15 shared a lot of logic) supported the RP02 
and RP03. But how did the RP15 do it? The XVM Systems Manual is useless, 
for example: it mentions the RP03 but shows formats that apply only to 
the RP02 (8b cylinder address).


I've spent (wasted) this whole day going through the 1975 revision of 
the RP15 prints, and I can now specify the very small set of changes 
that were made in the RP15 to support the RP03:


1. The cylinder address register was expanded to 9b.

2. An additional interface line was defined from the disk drive ("I am 
an RP03").


3. The logic for detecting end of pack/illegal cylinder address was made 
conditional on the RP03 status line:

 end_of_pack = (RP03? 405: 202);
 illegal cylinder = cylinder > end_of_pack;

4. The load disk address instruction (DPLA) was modified to load a ninth 
cylinder bit from AC:

<0:7> = cylinder low order 8b
<8:12> = head
<13> = cylinder high order bit
<14:17> = sector

5. The read disk address instruction (DPOA) was modified to read back 
the ninth cylinder bit, in the same format.


6. The read selected unit cylinder instruction (DPOU) was modified to 
read back nine bits of cylinder and an RP03 indicator:

<0> = set if RP03, clear otherwise
<9:17> = current cylinder (in normal bit order)

The RP10-C also had to put the 9th cylinder bit in a spare location.

So in theory, software could test each disk drive to see if it is an 
RP03 and react accordingly.


It would be easy enough to add RP03 support to the RP15, but there's no 
indication (other than MUMPS) that software ever did anything with it. 
The problem was not file structures - DOS-15 used 18b block numbers, and 
an RP03 only had 80,000 blocks. Perhaps the RP03 came along too late, or 
customers were more interested in lower cost options like DECtape, the 
RF15, or the RK15 Unichannel solution.


/Bob

P.S. Some other fun things from the MUMPS listing... MUMPS supported two 
LP15 line printers, the second at device address 35. It also supported 
up to 10 instances of a true terminal mux/scanner called the DC01EB, 
about which there is no information beyond the references in the MUMPS 
listing and the Diagnostic Exerciser writeup. MUMPS did not support the 
Unichannel.


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

Re: [Simh] PDP-15/76

[Rich Alderson]

> Date: Tue, 15 Mar 2016 18:31:35 +0100
> From: Mattis Lind 

> We have a bunch of documents related to PDP-15 and XVM/DOS. Some of them
> does not appear to be present on bitsavers. If there are interest we will
> try to make an effort and have them scanned.

> http://www.datormuseum.se/documentation-software/pdp-15-documentation

Yes, please, preserving all of the documentation for the PDP-15 software
would be a very good thing, and you have a lot of manuals which would be
very useful to anyone attempting to program one (either SimH or a real
PDP-15).

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

Re: [Simh] PDP-15/76

[Mattis Lind]

We have a bunch of documents related to PDP-15 and XVM/DOS. Some of them
does not appear to be present on bitsavers. If there are interest we will
try to make an effort and have them scanned.

http://www.datormuseum.se/documentation-software/pdp-15-documentation


The documentation was the only thing that remained from the PDP-15
installation at Standard Radio & Telefon (part of the ITT company) that was
used for development of the ATC (Automatic Train Control) system.

/Mattis

2016-03-15 17:46 GMT+01:00 Bob Supnik :

> I've pulled together the hardware pieces for the PDP-15/76 (PDP-15 with
> UC15 PDP-11 IO processor), so now it's time to consider what software can
> be run.
>
> The most likely candidate is XVM/DOS-15. While vanilla DOS-15 had UC15
> support at some point, neither a complete source kit nor the appropriate
> restore DECtape images seem to be available. The XVM/DOS-15 kit has all
> required DECtapes, but it lacks the paper-tape elements. Fortunately, these
> exist in source form in the XVM/DOS-15 source kit.
>
> ABSL11 - a PDP-15 read-in mode tape that allows PDP-11 absolute binary
> tapes to be read into shared memory and moved to private memory. (This is
> not strictly necessary, because the PDP-11 side has its "hardware" binary
> loader via the LOAD command.) This is used to load PIREX. It must be
> assembled on the PDP-15.
>
> PIREX - a PDP-11 absolute mode tape that runs the PDP-11 IO executive. It
> has to be assembled on an -11, so the source must be loaded into an RT11
> system, assembled, and punched out as a binary paper tape image. It's
> possible that the macro11 cross assembler could be used instead.
>
> DOSSAV - a PDP-15 binary tape that restores a distribution kit (usually
> two DECtapes) to RF, RP, or RK disk. It must be assembled on the PDP-15. It
> uses PIREX.
>
> RKBOOT - a PDP-15 read-in mode tape that uses PIREX to boot a PDP-15
> operating system off the RK15 (an 18b RK11). It must be assembled on the
> PDP-15. It uses PIREX.
>
> /Bob
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] PDP-15/76

[Bob Supnik]

I've pulled together the hardware pieces for the PDP-15/76 (PDP-15 with 
UC15 PDP-11 IO processor), so now it's time to consider what software 
can be run.


The most likely candidate is XVM/DOS-15. While vanilla DOS-15 had UC15 
support at some point, neither a complete source kit nor the appropriate 
restore DECtape images seem to be available. The XVM/DOS-15 kit has all 
required DECtapes, but it lacks the paper-tape elements. Fortunately, 
these exist in source form in the XVM/DOS-15 source kit.


ABSL11 - a PDP-15 read-in mode tape that allows PDP-11 absolute binary 
tapes to be read into shared memory and moved to private memory. (This 
is not strictly necessary, because the PDP-11 side has its "hardware" 
binary loader via the LOAD command.) This is used to load PIREX. It must 
be assembled on the PDP-15.


PIREX - a PDP-11 absolute mode tape that runs the PDP-11 IO executive. 
It has to be assembled on an -11, so the source must be loaded into an 
RT11 system, assembled, and punched out as a binary paper tape image. 
It's possible that the macro11 cross assembler could be used instead.


DOSSAV - a PDP-15 binary tape that restores a distribution kit (usually 
two DECtapes) to RF, RP, or RK disk. It must be assembled on the PDP-15. 
It uses PIREX.


RKBOOT - a PDP-15 read-in mode tape that uses PIREX to boot a PDP-15 
operating system off the RK15 (an 18b RK11). It must be assembled on the 
PDP-15. It uses PIREX.


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

Re: [Simh] RTS/8 and DECnet

[Johnny Billquist]

On 2016-03-15 14:13, Paul Koning wrote:



On Mar 15, 2016, at 5:47 AM, Johnny Billquist  wrote:

...
I don't remember who I talk to, but it might have been Paul, but it appears 
DECnet-8 is pretty much Phase I, from what we figured out. Maybe DEC wrote some 
newer version that have not been found, since documentation and SPDs mention 
Phase II.


I saw an RTS/8 document that describes Phase I -- studied it some to see what 
Phase I protocol looks like.  The answer is: significantly different from Phase 
II, not interoperable, no plausible way to make it interoperate.  The key 
problem is that the NSP details are different, so a Phase I endpoint trying to 
talk to a Phase II endpoint would get lost.  Compare that to Phase II through 
IV where the NSP is basically the same -- Phase III adds retransmission, but 
the packet formats are upward compatible.

But I also remember hearing about Phase II on PDP-8 systems.  So it seems 
likely that Phase I was created at some time, only to be superseded by a Phase 
II implementation.


Like I said, I can't remember if it was you or someone else I was 
talking about DECNET-8 with.


But there are some things that looks slightly inconsistent with what I 
understood from Phase I, but it also seemed pretty clear not to be Phase 
II. But I'd be happy to look more at it, if someone is interested.


And I think Bob asked about the physical links. DECNET-8 do use standard 
serial ports, and there is a DDCMP implementation in the software.


Johnny

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

Re: [Simh] RTS/8 and DECnet

[Paul Koning]

> On Mar 15, 2016, at 5:47 AM, Johnny Billquist  wrote:
> 
> ...
> I don't remember who I talk to, but it might have been Paul, but it appears 
> DECnet-8 is pretty much Phase I, from what we figured out. Maybe DEC wrote 
> some newer version that have not been found, since documentation and SPDs 
> mention Phase II.

I saw an RTS/8 document that describes Phase I -- studied it some to see what 
Phase I protocol looks like.  The answer is: significantly different from Phase 
II, not interoperable, no plausible way to make it interoperate.  The key 
problem is that the NSP details are different, so a Phase I endpoint trying to 
talk to a Phase II endpoint would get lost.  Compare that to Phase II through 
IV where the NSP is basically the same -- Phase III adds retransmission, but 
the packet formats are upward compatible.

But I also remember hearing about Phase II on PDP-8 systems.  So it seems 
likely that Phase I was created at some time, only to be superseded by a Phase 
II implementation.

paul


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

Re: [Simh] RTS/8 and DECnet

[Johnny Billquist]

On 2016-03-15 04:41, Ethan Dicks wrote:

On Mon, Mar 14, 2016 at 11:30 PM, Robert Armstrong  wrote:

   I just skimmed the manual, but it looks like DECnet-8 was really limited.  
It's basically a toolkit for writing your own applications that talk via 
DECnet; the only standard applications supplied are TLK and LSN (sort of the 
PDP-8 equivalent to PHONE).  There's no FAL, NFT or RMT task.  It doesn't seem 
like there's much you can do with it unless you want to write a bunch of 
software first.

   Or is there something I'm missing?


I think you pretty much have it there.  It was really limited.


Yeah. I've read through the code, and that's about it. You have the 
basic services so that you can write your own programs that communicate 
over DECnet, but there are very few standard programs supplied. I wonder 
if TLK/LSN might actually be compatible with the ones under RSX. Quite 
possible.
But there is not much else. But that not so unlike RTS/8 itself. RTS/8 
is not really much of a generic OS. You build it, along with the tasks 
that you want to run, from sources, and then you run the whole thing. 
There is no way of adding and removing tasks in an existing system. It 
is rather static.
The best it can offer is that you can have OS/8 as a background task in 
there, so that you can run random generic programs in that environment.


I don't remember who I talk to, but it might have been Paul, but it 
appears DECnet-8 is pretty much Phase I, from what we figured out. Maybe 
DEC wrote some newer version that have not been found, since 
documentation and SPDs mention Phase II.


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