[Simh] Design considerations in the J11

[Bob Supnik]

The J11 was started in mid 1979, in the subsection of Small Systems 
Engineering (the low-end PDP11 group) that handled microprocessor 
design. In the prior six months, I had been working as a systems 
analyst/product strategist in SSE and moonlighting as a microprogrammer 
on the F11 CIS option. I wrote a strategy paper recommending two 
projects: a 32b VLSI VAX and one last PDP11 microprocessor. Both 
recommendations were accepted. The 32b VLSI project was Scorpio (V11), 
and the PDP11 project was J11.


J11 was intended to converge the three different lines of PDP11 
development that had emerged in the early and mid 70s:


- Low end systems (11/05 -> LSI11 -> F11)
- Mid range systems (11/40 -> 11/34 -> 11/44)
- High end systems (11/45 -> 11/70)

It would be the logical successor to the LSI11 and F11 in the Qbus board 
and systems space, but it would have the performance and features of the 
high-end processors, including the never-shipped MPs.


This led to the basic requirements:

- 11/70 feature set (two general register sets, three modes, PIRQ, cache 
support, I and D space), plus more recent add-ons, like CSM and 
interlocking ASRB.

- 11/70 class performance, by running at 5Mhz (200ns cycle time).
- Integral and accelerated floating point.
- CIS option.

Some features were dropped, like the trapping (as opposed to faulting) 
memory management modes; they were not used by RSTS/E or RSX11M+. And an 
opportunity was missed: to use bits in the PDR to increase physical 
memory space beyond 4MB.


By the time J11 finally shipped in 1983, the "all-in on VAX" strategy, 
promulgated by Gordon Bell before he left, was in full swing, and 
further technology investments in PDP11 CPUs were discouraged. 
Accordingly, the CIS option was dropped, as was any thought of a 
successor product. Dom LaCava and Jesse Lipcon spun variants on J11 
through the end of the 80s and made the PDP11 group one of the most 
profitable in DEC. In the 90s, Mentec created a PDP11 CPU (M11) using 
off-the-shelf VLSI parts, and then reimplemented it as an ASIC (M1).


A couple of anecdotes:

- In order to have a "CAD forward" strategy, with tools replacing paper 
design, I asked Dick Clayton, the responsible VP, for a dedicated KS10 
(1/3 of a mip!) for the project. He thought this was totally outrageous 
- a dedicated time-sharing system for just one team! - but eventually 
authorized the acquisition.
- The Harris team had no experience with high-speed design and some its 
issues, such as metastability. The first schematics were filled with 
hazards. The chief Harris circuit designer was summoned to Hudson MA, 
and Bob Stewart - who had discovered and fixed the metastability issues 
in the 11/45 - patiently taught a multi-hour tutorial on metastability 
and the need for stacked flip-flops. The Harris designer kept proposing 
workarounds, and Bob patiently analyzed the results and showed that the 
hazard has simply been moved somewhere else.
- Interconnect verification (IV) on the T11 had taken months of tedious 
hand labor, and it was only 17,000 transistor sites. The J11 was much 
larger. Accordingly, the J11 team hired a small army of summer students 
to create a machine-readable netlist from the paper circuit schematics 
and used the KS10 to do computer based IV - a first for DEC.


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

Re: [Simh] Simh Digest, Vol 198, Issue 16

[Bob Supnik]

Yes, the PDP11 Architecture Handbook was a post-facto effort. The J11 
was finished; DEC did not intend to do another PDP11 processor. (I wrote 
a spec for one, primarily as an exercise in trying to do a different 
microcode structure than the PLA/ROM of the LSI11/F11/J11, but I lost 
it.) The only formal part of the PDP11 architecture was the Commercial 
Instruction Set extension, DEC STD 168, which was only implemented by 
the F11 and the 11/44.


Variances in the PDP11 architecture were the driving force behind the 
precision of the VAX architecture effort; and the problems in how 
floating point was implemented were the driving force behind Mary 
Payne's relentless efforts to make VAX floating point "good to the last 
bit," as she put it.


/Bob

On 7/9/2020 8:55 PM, simh-requ...@trailing-edge.com wrote:

Re: [Simh] pdp11 fails MAINDEC CPU test 14 D0NA


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

[Simh] DEC H-500 Computer Lab Reproduction

[Bob Supnik]

Mark Emmer sent me this link:

https://www.instructables.com/id/DEC-H-500-Computer-Lab-Reproduction/

It's a step by step guide, with parts and 3D print files, for building a 
reproduction of the late 60s DEC "Computer Lab" teaching toy. The site 
also includes the PDF files from the original.


An interesting project for the do-it-yourselfers on this list.

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

Re: [Simh] DG Nova announcement from Poul-Henning Kamp

[Bob Supnik]

Very cool. Is there any way to download the entire set of files at once, 
as an archive?


On 6/27/2020 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Fri, 26 Jun 2020 17:48:09 +
From: Lars Brinkhoff
To:simh@trailing-edge.com
Subject: [Simh] DG Nova announcement from Poul-Henning Kamp
Message-ID:<7wbll53ehy@junk.nocrew.org>
Content-Type: text/plain

Hello,

Poul-Henning Kamp asked me to post this to the list:



Just to let the SIMH/Nova users know that we have put a pile of
papertapes online in DataMuseum.dk:

 https://datamuseum.dk/wiki/Bits:Keyword/COMPANY/DATA_GENERAL/NOVA

Enjoy,

Poul-Henning

PS: We have much more, including what looks like ALGOL & FORTRAN,
 but RDOS is not a primary interest for us, so it will remain
 offline until somebody comes to Copenhagen on Thursday evenings
 to digitize it.  Email me if interested.




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

Re: [Simh] A lost 18b peripheral

[Bob Supnik]

Thanks, Tim. In terms of documentation, CSS is kind of a black hole. I 
don't know what happened to their archive, but it doesn't seem to have 
ended up at CHM. The RB09 (used in unix v0) found its way into an early 
PDP-9 Handbook, but that was a fluke.


Reindert Voorhorst found a DC01-EB exerciser listing. The XVM/MUMPS15 
scanner code is mostly in a separately assembled module that is not 
included with the listing we have.


Perhaps, like the KS11, we'll never know exactly how this gadget worked. 
Without MUMPS15 sources, it's a moot point.


/Bob

On 5/25/2020 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 3
Date: Mon, 25 May 2020 09:59:09 -0400
From: Timothe Litt
To:simh@trailing-edge.com
Subject: Re: [Simh] A lost 18b peripheral
Message-ID:
Content-Type: text/plain; charset="utf-8"

On 25-May-20 09:29, Bob Supnik wrote:

Looking through the XVM/MUMPS15 listing, I saw that the timesharing
terminals were attached via a DC01 communications multiplexer. There's
no reference to such a device anywhere in the 18b literature on
Bitsavers.

Because the PDP15 is a contemporary of the PDP8/I and the KI10, I
thought it might be a variant of their multiplexers, but I can't find
a match.

Another mystery.

/Bob


The DC01 was a CSS product.  Option/module reveals that it was adapted
for the 8, 9, 15 & 11.  You may find some hints in the other families,
though as you know, registers tend to have family ties...

   * DC01-AA 8 line scanner full duplex tty &/or EIA  \
   * DC01-AB 8 TTY scanner half duplex    \  8 POS
   * DC01-AC 8 Asyn scan full duplex EIA 3 cycle /
   * DC01-AL Full duplex line unit for DC01-AA
   * DC01-BB 8 TTY line scanner 1/2 duplex echo  PDP-9
   * DC01-EA 8 Line scanner full duplex (tty &/or
 EIA) \
   * DC01-EB 8 TTY line scanner half duplex echo +
 logic       \ 15
   * DC01-EC 8 Line async scan full duplex EIA 3
 cycle    /
   * DC01-ED 8 Line async scan, half duplex echo tty or EIA Sep. speeds /
   * DC01-FA 8 line scanner full duplex (TTY &/OR EIA)  \
   * DC01-FD Improved DC01-FA  \ 11
   * DC01-FJ 32 line scanner, full duplex, can use any DF11 interface

Responsible engineers: B. Vachon, Bill Weiske, D. Hopkins, J. Larkin,
Reg Wetherall, J. Stefanowicz, Russ Moore

-- next part --
An HTML attachment was scrubbed...
URL:<http://mailman.trailing-edge.com/pipermail/simh/attachments/20200525/66a65ddb/attachment-0001.html>

--

Subject: Digest Footer

___
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] A lost 18b peripheral

[Bob Supnik]

Looking through the XVM/MUMPS15 listing, I saw that the timesharing 
terminals were attached via a DC01 communications multiplexer. There's 
no reference to such a device anywhere in the 18b literature on Bitsavers.


Because the PDP15 is a contemporary of the PDP8/I and the KI10, I 
thought it might be a variant of their multiplexers, but I can't find a 
match.


Another mystery.

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

[Simh] Lost (18-bit) operating systems

[Bob Supnik]

Before MUMPS-11, there was MUMPS-15. It is the only one of the PDP-15's 
DEC operating systems that is still missing. TA PDF assembly listing of 
XVM/MUMPS-15 (or perhaps only part of it) exists, but it is scribbled 
over in places, as though it were a developer's "in progress" listing.


There's also a pocket card for a PDP-9 timesharing system developed at 
the Ontario Institute for Studies in Education. No other trace has been 
found.


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

Re: [Simh] Simh Digest, Vol 194, Issue 67

[Bob Supnik]

Thanks, Matt. I would never have thought to look there.

/Bob

On 3/24/2020 9:11 AM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Tue, 24 Mar 2020 01:05:39 +
From: Matt Burke
To:simh@trailing-edge.com
Subject: Re: [Simh] VAX 750 and 730 (was Is it possible to simulate
the first Vaxen I ever used?)
Message-ID:<0fc8ba2d-1853-45fa-bd2f-953029213...@9track.net>
Content-Type: text/plain; charset=utf-8

On 23/03/2020 19:16, Bob Supnik wrote:

One of the problems with simulating the non-VLSI VAXen, other than the
780, is that the microcode is not available. Back at DEC, I had the
730 microcode in a huge notebook (it was 16KW), but I discarded it
when I moved out of Hudson and downsized my document collection. We
really need the microcode for the 750, 730, 8600/8650, 8200 (V11), and
8800.

The various microcodes may be available in the DEC fiche collection at
CHM, but I haven't been able to get out there to do the research, and
travel is out of the question right now.


The 11/750 microcode listing is available on Bitsavers (not under the
directory you might expect though):

http://www.bitsavers.org/pdf/dec/pdp11/xxdp/fiche_200dpi/0187_CMT098.MCX_750uCod.pdf

Matt


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

[Simh] VAX 750 and 730 (was Is it possible to simulate the first Vaxen I ever used?)

[Bob Supnik]

One of the problems with simulating the non-VLSI VAXen, other than the 
780, is that the microcode is not available. Back at DEC, I had the 730 
microcode in a huge notebook (it was 16KW), but I discarded it when I 
moved out of Hudson and downsized my document collection. We really need 
the microcode for the 750, 730, 8600/8650, 8200 (V11), and 8800.


The various microcodes may be available in the DEC fiche collection at 
CHM, but I haven't been able to get out there to do the research, and 
travel is out of the question right now.


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

[Simh] RT11 init

[Bob Supnik]

And the solution is... a stock RT-11 distribution only has  RL drives.

; SYSTEM GENERATION OPTION

.IIF NDF DL$UN, DL$UN   == 2;NUMBER OF UNITS SUPPORTED
.IIF GT DL$UN-4, DL$UN  == 4;CAN'T HAVE MORE THAN 4 UNITS
.IIF LE DL$UN,  DL$UN   == 1;CAN'T HAVE NO UNITS

Doing  on DL2 or DL3 ain't gonna work.

On DL1, you can init an RL02 just fine.

If you want to play with DL2 and 3, run SYSGEN.

/Bob


Message: 1
Date: Wed, 12 Feb 2020 12:30:30 -0500
From: "Ken Hall"
To:
Subject: [Simh] Initializing disks (triggered by the "Something
Strange withRK05" chain
Message-ID:<004601d5e1ca$1ff019d0$5fd04d70$@gmail.com>
Content-Type: text/plain; charset="utf-8"

I've played with RT11 on and off over the years, but the one thing I've
never been able to do is properly initialize an empty disk.  If I create a
DL2: for example, and try to run initialize on it, I get back:

 


.dir dl2:

?DIR-F-Error reading directory

 


.init dl2:

DL2:/Initialize; Are you sure? YES

?DUP-F-Size function failed

 


This seems similar to the issues Henk Gooijen has been having with RK05's,
and it's been so long since I've dealt with the real hardware I don't recall
exactly how this is supposed to work, but it seems to me it should just
"work".

 


Has anyone found a solution to this?

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

[Simh] RK formatting - closed

[Bob Supnik]

The simulator is doing the right thing. Here's the core of the 
formatting routine:


6$: MOV #-1,RKWC(R2)    ;SET WORD COUNT TO 1
    MOV #RKDATA,RKBA(R2)    ;SET BUFFER ADDRESS
    MOV #WRTFMT+GO,RKCS(R2) ;ISSUE WRITE FORMAT
7$: BIT #CTLRDY,RKCS(R2)    ;DONE?
    BEQ 7$  ;NO-WAIT
    BIT #ERR,RKCS(R2)   ;REACHED ERROR CONDITION YET?
    BEQ 6$  ;NO. REPEAT 'TILL ERROR CONDITION
    ADD #14533,R1   ;COMPUTE LAST VALID ADDRESS ON DISK
    CMP R1,RKDA(R2) ;ARE WE THERE?
    BHI 9$  ;NO. ERROR
    MOV #CTLRST+GO,RKCS(R2) ;CLEAR CONTROLLER
8$: BIT #CTLRDY,RKCS(R2)    ;DONE?
    BEQ 8$  ;NO-WAIT
    BIT #ERR,RKCS(R2)   ;ERROR?
    BNE 9$  ;YES, BUT ERROR
    CLC ;NO ERRORS.
    BR  11$ ;GO TO RETURN

9$: $ERROR  #$SERR2,F   ;'?DEVICE ERROR'    ;MG1
10$:    SEC ;INDICATE ERROR
11$:    RTS PC  ;RETURN

And here's the simulator coming out of the loop:

.format rk0:
RK0:/FORMAT-Are you sure? Y

Breakpoint, PC: 012736 (ADD #14533,R1)
sim> s

Step expired, PC: 012742 (CMP R1,12(R2))
sim> s

Step expired, PC: 012746 (BHI 13002)
sim> s

Step expired, PC: 012750 (MOV #1,4(R2))
sim> s

Step expired, PC: 012756 (BIT #200,4(R2))
sim> s

Step expired, PC: 012764 (BEQ 12756)
sim> s

Step expired, PC: 012766 (BIT #10,4(R2))
sim> s

Step expired, PC: 012774 (BNE 13002)
sim> s

Step expired, PC: 012776 (CLC)
sim> s

Step expired, PC: 013000 (BR 13020)
sim> s

Step expired, PC: 013020 (RTS PC)
sim> c
?FORMAT-I-Formatting complete

As you can see, the code resets the controller, sees no errors, and 
continues onward.


I regard the issue as resolved. The simulator is handling formatting 
correctly, and RT11 is generating an appropriate informational message 
at the end.


/Bob

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

[Simh] RT11 sources needed

[Bob Supnik]

Okay. If I'm going to trace this RK11 FORMAT bug and RL02 init bug, I 
need sources (with comments) for some version of RT11 that supports 
those devices, like V5.3 or later. Both are probably in DUP, but I'd 
need to trace driver code too.


Over the years, I've managed to stockpile sources for various PDP11 
operating systems, but never RT11.


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

Re: [Simh] Various

[Bob Supnik]

1. I can confirm that RT11 V5.3 INIT does not work properly with an RL02 
in 3.10.


My next step is to trace back changes, because I think it used to work.

2. There's no card reader for the SDS 940 because

a) I hate card readers (from having used them way back when)
b) I thought there wouldn't be any demand

Rich Cornwell's library should make it easier to implement a card reader
these days.

My first card reader story goes back to an RCA Spectra 70 I used in 1965.
It had a vacuum pick reader for high speed operation. The reader would
gradually curl the front edge of the cards, so that after two or three
passes, the deck was unreadable. It's failure mode was to spit cards out,
past the receive hopper, at very high velocity and scatter them ten or
fifteen feet out on the floor...

The second was a very slow mechanical reader on a PDP-7 in 1966. The
only other keyboard device was a Teletype, so initial entry of programs
was done from punched cards. It read, allegedly, 100 cards per minute
using mechanical fingers with little star wheels on the end. DEC field
service was in almost every week tuning or fixing the damned thing so
that it could actually handle a decent-sized deck.

In my experience, only IBM built decent card readers. The reader/punch
on the 1620 (I used one in 1964) was very sturdy, and the 407 (used for
offline printing of punched card output) could read almost anything.

/Bob


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

[Simh] Subject: Re: something strange with simulated RK05 drive ?

[Bob Supnik]

To my surprise, format is actually mechanized in the RK11 simulator. 
Whether it's mechanized correctly is another story, of course.


There are only two tests for the format bit.

1. If FORMAT is set when GO is set, and the command is anything other 
than READ or WRITE, then PGE (programming error)
    is set, and the operation terminates. (See the RKER register 
description.)
2. If FORMAT is set during READ, one header word is transferred from 
consecutive sectors to fill the buffer.


According to the maintenance course, the header is just the cylinder 
address, positioned as in RKDA.


Write + Format is the same as write, except that the header is not 
checked for being on the correct cylinder before writing the sector. 
Normal writing always rewrites the header word. So a "real" format 
program can write a bad drive, with incorrect headers. The simulator can't.


Personally, I've never tried RT-11 FORMAT, and I sort of feel this way 
about it:


Patient: "It hurts when I do that!"
Doctor: "Don't do that."

However, if someone has RT11 source code and wants to trace what's going 
on, I can dig deeper.


/Bob

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

Re: [Simh] PDP-11 -- MFPI, etc, with memory mgmt off

[Bob Supnik]

If the MMU is enabled, the instructions use PSW to compute 
the source/destination operand physical address (if memory) or the stack 
pointer to use (if SP). If the MMU is off, PSW only matters 
if the source/destination operand is SP.


/Bob

On 9/22/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 4
Date: Sun, 22 Sep 2019 09:01:42 +0200
From: Johnny Billquist
To:simh@trailing-edge.com
Subject: Re: [Simh] PDP-11 -- MFPI, etc, with memory mgmt off
Message-ID:<158acaa4-22c1-bb9c-ecdf-3c2b5d273...@softjar.se>
Content-Type: text/plain; charset=utf-8; format=flowed

Well, technically, on a Unibus, even with the Unibus map, a DMA device
still only sees an 18-bit address. Or am I confused? But if the map is
enabled, then it will end up being able to access all 4M of memory anyhow.

But your answer made me wonder. Are you saying that M[TF]P[DI] are not
using the previous mode bits in the PSW (when MMU is enabled)? Oh, maybe
you are saying that even if MMU is disabled, the selection of which R6
to use is still happening, based on PSW.

Johnny



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

Re: [Simh] PDP-11 -- MFPI, etc, with memory mgmt off

[Bob Supnik]

Seems like an appropriate question to me.

The answer is no. If the MMU is not operating, the MT/FPI/D instructions 
operate on physical addresses and are limited to 16bit addresses.


The PSW mode bits (in particular, previous mode) are operative for 
choosing which stack pointer is used if the operand specification is R6. 
So MTPI SP will store the operand popped from the stack in the stack 
pointer selected by PSW. The address calculation on the stack 
is purely physical, ie, 16 bits.


If the MMU is not enabled, programs can only see memory addresses 00 
- 15 and the IO page. DMA devices can see (on the Unibus or the 
original Qbus) 18 bits of memory addresses or (on the Q22 bus or a 
Unibus system with an IO map) 22 bits of memory addresses.


/Bob Supnik

On 9/21/2019 8:24 PM, simh-requ...@trailing-edge.com wrote:

Message: 2
Date: Sat, 21 Sep 2019 19:49:39 -0400
From: "dave porter"
To:
Subject: [Simh] PDP-11 -- MFPI, etc, with memory mgmt off
Message-ID: <98F67D8C56794670847F6C44F7EE968F@street>
Content-Type: text/plain; format=flowed; charset="UTF-8";
reply-type=original

I hope you'll excuse a non-SIMH question on this list.

Over in the retrocomputing forum on Stack Exchange,
I'm involved in a conversation that says that the
11/73 move to/from previous-mode space instructions
MTPI, MTPD, MFPI, MFPD, will, when the MMU is
not enabled, use the previous-mode bits from the
PS directly as bits 16,17 of the physical address.

I've never heard of such a thing and I cannot find
anything written that really says what these
instructions do when running unmapped.

Anyone know about this?  (Mr. Supnik?)

If I shouldn't have asked this non-SIMH question
on this list, just say so and I won't do it again.
Thanks.



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

Re: [Simh] VAX + Spectre

[Bob Supnik]

Funny you should ask. The short answer is no. No VAX ever did 
speculative or out of order execution.


Three developments had to come together for Spectre-style bugs:

1. Speculative execution that affects the cache or other indirectly 
testable state.
2. A high-precision, user-mode timer (for measuring cache or branch 
table perturbation effects).
3. A 'close-in' entity that can do low-latency measurements - the other 
thread(s) in a hyper-threaded CPU; another core in a multi-core chip; 
another processor on a SMP bus with extremely fast response time.


The VAX lacked all three. Aquarius and NVAX pipelined instruction 
execution, but they did not go out of order. The high-precision timers 
were IPRs only accessible in kernel mode. And the other processors in an 
SMP were very 'distant' in modern terms.


While IBM gets the credit (or blame) for speculative execution, it was 
Intel's decision to allow speculation to perturb the data cache that put 
the cat among the pigeons. Tthe high-precision user mode timer started 
with Alpha's cycle timer. As for close-in entities... the roots are 
tangled. Hyperthreading was in the air in the mid to late 90s; EV8 was a 
four-way threaded design. So was multicore - the WRL chip team proposed 
an eight-core EV56 as a cheaper-to-design-and-build alternative to EV8.


A more interesting question - and one more relevant, since a lot of 
Alphas are still running - is whether Alpha (in particular, EV6) is 
vulnerable. Again, I'm pretty sure the answer is no.  While EV6 did 
speculative execution, it would not allow speculative loads or stores to 
perturb the cache. It would be very difficult to exploit the branch 
prediction or subroutine return prediction tables, because they would be 
massively perturbed by any switch to a measurement thread or process. 
And theAlpha interprocessor SMP buses were too slow to allow effective 
measurements by a different processor.


/Bob

On 9/17/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Tue, 17 Sep 2019 09:55:01 -0400
From: Paul Koning
To: SIMH, "General Discussion: On-Topic and
Off-Topic Posts"
Subject: [Simh] Fwd: VAX + Spectre
Message-ID:<21f0e611-e49f-422a-9d66-edba660ad...@comcast.net>
Content-Type: text/plain; charset="utf-8"

"Spectre" is one of two notorious bugs of modern CPUs involving speculative 
execution.  I rather doubt that VAX is affected by this but I suspect others here have a 
lot more knowledge.

paul


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

Re: [Simh] The Missing PDP-8s

[Bob Supnik]

Well, no. It's a PDP-8/A as initially released and documented in the 
late 1976 PDP-8/A manuals and schematics. That machine was limited to 
32KW. So was the initial, 1976 version of the FPP8-A.


The KT8-A was released in mid 1978. It expanded memory capability to 
128KW and added a number of other interesting features. It wouldn't be 
that hard to add it.


The 8/A was not the end of the line, of course. The Intersil 6100 and 
Harris 6120 took the PDP8 into VLSI and added additional features.


I'm not sure where I'd draw the line between static and dynamic 
compilation of models. Different simulators have taken different approaches:


- The PDP11 allows the model to be set dynamically, except for the UC15.
- The VAX requires the model to be compiled statically (every VAX model 
is a different simulator).
- The PDP10 requires the model to be compiled statically, but the type 
of memory management can be selected dynamically on the KS10.
- The 18b PDPs require different models to be compiled statically, but 
the type of memory management can be selected dynamically on the PDP9 
and PDP15.


I don't think it's impossible to make a dynamic 'all-in-one' PDP8 CPU. 
You'd have to identify how the earlier machines handled 'unpredictable' 
results, e.g., RTL!RTR, but working examples of every PDP8 (not the 
PDP5, though) are still extant if questions need to be answered. IO is 
uglier. The PDP5 and classic PDP8 used peripherals similar to the PDP4 
and PDP7, like the type 552 magtape and type 555 DECtape controllers. 
Starting with the 8/I, we see the "modern" form of storage controllers. 
However, the 8/I still uses the older type 645 line printer controller 
instead of the newer LP8E/LP8A. The serial drums from the classic 8 made 
it to the 8/I but were superseded by the DF32 and then the RF08. 
Real-time clock programming is very different from the old models to the 
new ones. Etc, etc, and so forth.




On 8/13/2019 3:51 PM, Warren Young  wrote:

It's a mongrel. SIMH's FPP (floating point processor) peripheral emulates
the version for the 8/a, but memory is limited to 32 kWords as in all
models before the 8/a, which added a mode to allow 128 kWords of core or
semiconductor RAM.


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

Re: [Simh] The Missing PDP-8s

[Bob Supnik]

As was pointed out, the existing PDP-8 CPU is basically a PDP-8/E or 
-8/A. It doesn't have the model-specific capabilities of the current 
PDP-11 CPU simulator.


Making the PDP-8 "model specific" is a bit more difficult than just 
putting in model tests at various points in the CPU. The peripherals, 
and the peripheral instruction sets, evolved too. The PDP-8's DECtape 
controller is quite different from the TC08; the magtape controller is 
different as well. With the 8/E, the original IOP 1,2,4 scheme was 
replaced with the OmniBus, allowing peripherals to decode as many as 8 
instructions per device code, instead of 3 or 4.


As for the PDP-5... it probably has different major peripherals too. So 
it's not just the PC = location 0 problem.


I looked at a PDP-12 implementation. It's not hard, but I really didn't 
want to do Yet Another DECtape Simulator for Linctape. With Rich 
Cornwell's recent work, it's clear that the DECtape controllers should 
have been abstracted to a library ten years ago, but doing so would be a 
major PITA, now that there are six (at least) distinct implementations 
(PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10).


/Bob

On 8/13/2019 5:19 AM, simh-requ...@trailing-edge.com wrote:

Has any ever thought of writing simulators for the two missing systems, the
PDP-5 and the PDP-12?


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

Re: [Simh] Release of PDP10 KA/KI and PDP6 simulators.

[Bob Supnik]

Great job, Rich, and congratulations.

Maybe we'll have 4S72 (or whatever it was called), the first version of 
TOPS-10 I ever used...


/Bob

On 7/10/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 2
Date: Wed, 10 Jul 2019 07:29:14 -0400
From: Richard Cornwell
To:simh@trailing-edge.com
Subject: [Simh] Release of PDP10 KA/KI and PDP6 simulators.
Message-ID:<20190710072914.5794ecb8.r...@sky-visions.com>
Content-Type: text/plain; charset=US-ASCII


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

Re: [Simh] PDP11 microstore

[Bob Supnik]

The PLA scheme (another invention from the fertile mind of Bill Roberts, 
architect of the LSI11 and UDA50 proto and founder of Emulex) was 
basically a microcode and gate conservation scheme. It provided enormous 
compression for the decode phase of the PDP11 and then got exploited to 
a fare-thee-well by clever microcoders like Burt Hashizume (F11) and 
Keith Henry (J11).


Sometime during the 80s, when it became clear that the process problems 
with the J11 were intractable, and it could not be shrunk for higher 
performance, I outlined a design for a single chip PDP11. Because ROM 
densities and transistor counts were so much higher by then, I felt it 
could all be done in ROM, using the usual "indirection pointers" like Rs 
and Rd for source and destination registers and a fairly simple initial 
decoding scheme to break out the interesting cases. I didn't save 
anything about it in my online archive, so I don't know what happened to 
the design notes. The idea didn't go anywhere, of course; the PDP11 was 
clearly on its last legs by then.


/Bob

On 7/1/2019 2:36 PM, simh-requ...@trailing-edge.com wrote:
Message: 2 Date: Mon, 1 Jul 2019 10:50:51 -0600 From: Eric Smith 
 To: simh@trailing-edge.com Subject: Re: [Simh] 
Which PDP-11 to choose Message-ID: 
 
Content-Type: text/plain; charset="utf-8" 

IIRC Bob has written that no one has succeeded at building an alternate J11
hardware implementation, e.g., in an FPGA., because the microcode is not
entirely ROM. There is a fairly large (for the time) PLA forming part of
the control store. The PLA could be transformed into a ROM, but IIRC it has
_many_  inputs, so the ROM would be YUGE.

Almost 20 years ago I wrote a program to translate the PLA into VHDL
directly instantiating Xilinx 4LUT primitives to see how much resources it
would consume in e.g. a Spartan 3 FPGA. I don't recall the numbers, but it
didn't seem insurmountable at the time, and with today's bigger FPGAs and
6LUTs, it's even less of a problem.

Also, I think the synthesis tools are good enough that just giving the PLA
equations to synthesis would be fine, and my scheme of programmatically
transforming the equations to LUT instantiations is totally unnecessary.

Eric


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

Re: [Simh] SimH as microcode simulator

[Bob Supnik]

SimH is pretty much a knockoff of MIMIC, which was used for microcode 
verification of the LSI11... so it should work fine.


For microcode, the hardware has to be modeled with extreme care, 
particularly for operations happening in parallel, and the timing has to 
be accurate. Most SimH simulators time in instructions, but that's 
arbitrary. You can time in any unit you want (like nanoseconds). STEP 
would require some work, of course.


/Bob

On 7/1/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 3
Date: Mon, 01 Jul 2019 15:59:42 +
From: Lars Brinkhoff
To:simh@trailing-edge.com
Subject: Re: [Simh] Which PDP-11 to choose
Message-ID:<7wblydbv9t@junk.nocrew.org>
Content-Type: text/plain

Bob Supnik wrote:

The J-11 based simulators (11/73 and up) are the only ones that were
verified against actual machine microcode.

Speaking of which.  Someone claimed SIMH wouldn't be well suited for a
microcode level simulation.  Is there any truth to this?  If so why?

Asking for a friend.




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

Re: [Simh] Which PDP-11 to choose

[Bob Supnik]

If I may interject a serious note...

The J-11 based simulators (11/73 and up) are the only ones that were 
verified against actual machine microcode. The 11/73 system was the only 
one verified against its board and system specification. The others are 
all derivatives.


I always debug with the 11/73. It has 4M memory, I/D space, and access 
to large disks via the MSCP controller.


/Bob

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

[Simh] RP vs RM header operations

[Bob Supnik]

As I suspected, RP class drives (except the RP07) have 4 words of 
header, and RM class drives have 2. This is confirmed by the RSTS/E disk 
initialization code. RSTS/E can't format an RP07, so I can't verify how 
those functions ought to work. RSTS/E seems to think it has 2 words of 
header, though.


Any implementation of the write/write check/read header functions needs 
to take care of the header words properly. Assume, for example, that 
SALV is trying to write an entire RP06 track (20 sectors/track). It 
would specify a Massbus  count (in 18b words) of 20 * (4 + 256) = 
5200 words. If write track plus header just defaults to being a normal 
write, then 80 words will spill over to the start of the next track. 
That might not matter if the next track is promptly overwritten, but on 
the last track, the extra words will generate an addressing error, and 
SALV will (probably ) fail.


For an RM, the count needs to be 30 * (2 + 256) = 7740 words. Again, if 
the two extra words aren't accounted for, the last track write will 
overflow and generate an error.


RSTS/E formats both RPs and RMs the same way: cylinder (plus 16b flag) 
in the first word, track/sector in the second. For the RP, the third and 
fourth are left as 0. There are bad block flags reserved in the header, 
but all SimH disks are perfect. ;)


tl;dr. If you're going to implement these functions as other than stubs, 
they better be done right, or other kinds of errors will surface.


/Bob


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

Re: [Simh] RP/RM differences in header commands (for ITS, salvager)

[Bob Supnik]

I don't think it's that straightforward. The write header and data 
command must include the proper Massbus word count for header and data. 
The Unibus side of the RH11 is doing 18b transfers, and so is the disk 
side, so the word count ought to be 260 for an RP and 258 for an RM.


If the simulator doesn't "skip" the right number of header words, SALV 
is going to fail on its block data check.


/Bob

On 6/26/2019 7:37 PM, simh-requ...@trailing-edge.com wrote:

I would vote for someone doing just the naive write as a starting point.
I think much software will be happy enough with just that, and then we
can look at specific when we locate software that really do care about
what is written into the headers.

Johnny


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

[Simh] RP/RM differences in header commands (for ITS salvager)

[Bob Supnik]

Implementing a more complete form of read/write/write check header is 
not as straightforward as I thought, because the RP and RM drives use 
different header formats.


The RP expects 4 16 bit words, of which the first two are used, and the 
second are "for software". Word 0 is cylinder plus 18b/16b, word 1 is 
sector, words 2 and 3 are "keywords".


The RM expects 2 16 bit words, both used. Word 0 is cylinder plus 
18b/16b plus two bad block indicators. Word is 1 is track and sector.


The simulator supports the RP06, RP07, RM02/3, RM05, and RM80. I'm not 
sure if the RP07, RM05, or RM80 were ever actually qualified for the 
KS10. However, the RP06 and RM02 both shipped with the system, so the 2 
word/4 word distinction would have to be implemented.


I can't find the sector format for the RP07 which, despite its name, 
behaved like an RM series drive.


/Bob

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

Re: [Simh] Name Confusion

[Bob Supnik]

You're quite right. Rolm is not Rohm & Haas. The Rolm MIMIC simulator 
was in the same box of ADR listings as a tensile tester package 
developed for Rohm & Hass, and I got the names confused.


On 6/26/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 4
Date: Wed, 26 Jun 2019 10:36:21 -0500
From: Jon Elson
To:simh@trailing-edge.com
Subject: Re: [Simh] Simh Digest, Vol 185, Issue 19
Message-ID:<5d1390f5.5010...@pico-systems.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

  wrote:

Rolm & Haas made a militarized Nova-compatible minicomputer called

Rohm & Haas made Plexiglas, and had nothing to do with the
Rolm corporation, which made phone switches and military
computers.

Jon



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

Re: [Simh] Rolm 1602

[Bob Supnik]

I'm fairly sure it existed. ADR (Applied Data Research) only wrote 
unusual MIMIC simulators when needed. IIRC, we did some sort of process 
control or analytical instrumentation project for Rolm & Haas itself, 
and they insisted the 1602 be used. The listing for that is probably in 
the attic too...


/Bob

On 6/25/2019 8:49 PM, Henry Bent wrote:
On Tue, 25 Jun 2019 at 20:41, Bob Supnik <mailto:b...@supnik.org>> wrote:


Rolm & Haas made a militarized Nova-compatible minicomputer called
the
1602 - a follow on to their 1601 Ruggednova system. It had an
extended
instruction set. I know this because I found the listings for the
PDP10
based 1602 simulator in my attic tonight. I've never seen any other
documentation.

I'm not sure this system adds anything to Nova lore, but if people
are
interested, I can try to compile a "feature set" from the PDP10
simulator code.

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


Was it actually used in production, or did it just exist in a 
simulator form?  I can easily imagine a simulator for such a thing 
being written but not surviving past a failed bid process, so no hardware.


-Henry


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

[Simh] Rolm 1602

[Bob Supnik]

Rolm & Haas made a militarized Nova-compatible minicomputer called the 
1602 - a follow on to their 1601 Ruggednova system. It had an extended 
instruction set. I know this because I found the listings for the PDP10 
based 1602 simulator in my attic tonight. I've never seen any other 
documentation.


I'm not sure this system adds anything to Nova lore, but if people are 
interested, I can try to compile a "feature set" from the PDP10 
simulator code.


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

[Simh] Read/write header in RP drives

[Bob Supnik]

I like Johnny's suggestion.

1. On write header, "eat" the two header words and then write normal data.
2. On read header, synthesize the two standard header words and then 
read the pack data.
3. On write check header, skip the first two (header) words and then do 
a normal write check.


This is what the DECtape simulators do with Read All and Write All. This 
solution would work on the PDP11/VAX RPs as well.


I also agree that the "white space" could be used to record the header 
information for 36b drives, but it would be safer to leave those bits as 
zeroes. If the upper 28b of simulated PDP10 memory ever held non-zero 
data, the CPU simulator would go off the rails, badly. And the solution 
would be unique to the PDP10 implementation.


/Bob



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

Re: [Simh] The Interconnect Task Force

[Bob Supnik]

The RC25 (code named Aztec) got started as I was leaving Storage 
Engineering. Mike Riggle, VP of Storage Advanced Development (and later 
Storage Engineering), recognized early on that to improve seek and 
rotational performance, disk diameters (14" for the RA8X series) had to 
shrink; 8" or 9" would be the next target. Mike wanted to do only sealed 
(Winchester) disks, but there was significant marketing pressure for a 
low-end removable disk to succeed the RK11, RK611, and RL11. Hence 
Aztec, later the RC25. LESI was, I believe, an attempt to cost-reduce 
the RA8X's radial disk interconnect while maintaining performance.


The RC25 was pretty much a disaster, technically and financially, and 
the end of the line for DEC's removable disk program. Low end systems 
went with ST504-compatible 5.25" sealed disks (the RDXX family), while 
the high-end went with 8" or 9" RA9X series, which used the RA8X radial 
interconnect. ST504 was eventually replaced by SCSI (and later its 
clusterable proprietary variant, DSSI).


/Bob

On 6/25/2019 7:22 PM, Robert Armstrong wrote:

Bob Supnik [b...@supnik.org] wrote:
Ah, yes, the Interconnect Task Force. 1980, perhaps?


   Can you say anything about LESI, "Low End Storage Interconnect"?  It was 
used by the RC25 and the TU81+ and, AFAIK, that's it.  It never really went anywhere and 
there's basically no documentation on it that I've ever seen.  I always wondered about 
the story behind that.

Thanks,
Bob






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

Re: [Simh] The Interconnect Task Force (was: Origins of MSCP)

[Bob Supnik]

Ah, yes, the Interconnect Task Force. 1980, perhaps? All my engineering 
notebooks are entombed at the Computer History Museum now.


CI - computer interconnect - realized in the passive "star coupler" and 
the CIxxx family of interfaces.
BI - backplane interconnect - realized in the BIIC chips - used as the 
memory and IO bus in the 8200 and the IO bus in several further systems. 
Superseded by the XMI, which was the memory and IO bus of the VAX 6000 
family and was later used as an IO bus.

NI - network interconnect - Ethernet. Success!
DI - device interconnect - intended as a low cost interconnect to 
devices - basically async serial. Really only used in the DECtape II 
implementation with its own simplified form of MSCP (Radial Serial 
Protocol).
II - interchip interconnect. This went nowhere at the time. The Semi 
Group standardized much later on the CVAX pin bus as a defacto "II" and 
created a family of pin-compatible chips. The CVAX pin bus morphed from 
a memory-and-IO bus in CVAX to an IO-only bus in later chips. Chips in 
the "CVAX pin bus family" included the memory controller (CMCTL), the 
console chip (CSSC), the second-generation Ethernet control (SGEC), the 
DSSI controller (SHAC), and the Qbus interface (CQBIC). The last three 
were used across multiple generations; the CMCTL and CSSC were only used 
in CVAX systems. Superseded, in most senses, by PCI in the 1990s.


About the only thing that was consistent in DEC's interconnect strategy 
was that one generation's memory and IO backplane interconnect became a 
pure IO backplane interconnect later. This was true of the Unibus, Qbus, 
BI, and XMI. Memory cards were easy to design and replace; IO 
controllers tended to live much longer.


/Bob

On 6/25/2019 1:33 PM, Paul Koning wrote:



On Jun 25, 2019, at 11:43 AM, Bob Supnik  wrote:

True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) 
advanced development project, which led eventually to both the HSC50 and the UDA50. Among 
the goals of the project were

1. To move ECC correction off the host and into the disk subsystem, so that 
much more powerful and complex ECC codes could be used.
2. To move bad block replacement off the host and into the disk subsystem.
3. To provide a uniform software interface for radically different disk drives.
4. To abstract away all device geometry information.
5. To implement command queuing and to perform all performance optimization, 
particularly seek optimization, in the disk subsystem.

#2 was only partially true in the UDA50 -- I remember an amazingly large body 
of code in RSTS for bad block replacement for the RA80 that's about 2000 lines 
of code -- roughly the same size as the rest of the MSCP driver.

I remember MSCP as part of the larger "Interconnect Architecture" effort, which produced 
a range of "interconnects" some of which seemed to become real and some less so.  There 
was the new peripheral bus (BI), the cluter interconnect (CI, computer interconnect) and one or two 
others.  I vaguely remember II (Interchip Interconnect) -- did that become I2C, or something else, 
or nothing?  And DI (device interconnect) ???  Also NI, which became Ethernet.  And XI?  I think we 
used that term in the networking group for the next generation high speed network.  Gigaswitch?  
FDDI?  Not sure.  Part of the impression I had was that there was some overall concept unifying all 
this, but whether that was actually realistic is not clear.

One place it showed up was in the Jupiter mainframe (which didn't happen), 
supposedly built around CI and NI as its connections to the outside world.

There's also XMI, but that was a generation later as I recall.
paul





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

Re: [Simh] Origins of MSCP

[Bob Supnik]

True. My first assignment at DEC was managing the "New Disk Subsystem" 
(NDS) advanced development project, which led eventually to both the 
HSC50 and the UDA50. Among the goals of the project were


1. To move ECC correction off the host and into the disk subsystem, so 
that much more powerful and complex ECC codes could be used.

2. To move bad block replacement off the host and into the disk subsystem.
3. To provide a uniform software interface for radically different disk 
drives.

4. To abstract away all device geometry information.
5. To implement command queuing and to perform all performance 
optimization, particularly seek optimization, in the disk subsystem.


From my recollection, the Massbus was actually regarded as the 
counterexample. First, the Massbus cables were massive and unwieldy; the 
radial drive interconnect for the RA-class drives were a direct 
reaction. Second, the Massbus exposed drive geometries, which made it 
impossible to implement a new disk type without a driver update; with 
MSCP, the subsystem reported capacities, and the operating system could 
set up a file structure accordingly... sometimes.


What the two protocols had in common was standardizing the format of the 
software [register (Massbus) / packet (MSCP)] interface. All Massbus 
disks used the same register sets... except when they didn't (the RP/RM 
divergence). All MSCP disks used the same packet formats... except for 
errors. But it was a lot better than the "every disk is unique" 
nonsense. DG had a standardized disk interface from the get-go.


/Bob

On 6/25/2019 8:10 AM, simh-requ...@trailing-edge.com wrote:

Message: 8
Date: Tue, 25 Jun 2019 08:10:08 -0400
From: Paul Koning
To: Timothe Litt
Cc: SIMH
Subject: Re: [Simh] Limits on MSCP controllers
Message-ID:<81262a49-f410-432c-8c00-4aa9ac585...@comcast.net>
Content-Type: text/plain;   charset=us-ascii




On Jun 24, 2019, at 5:27 PM, Timothe Litt  wrote:
As is often the case, things turn out to be complicated.  Here's a more detailed version. 
 In an off-list note, Bob pointed out that MSCP originated in a project he managed that 
was to develop the "next generation" disk controller - a forerunner of the UDA. 
  ...
However the similarities came to pass, I found viewing DSA as an evolved Massbus to be a useful 
model, with a lot of support for that perspective in the specifications.  MSCP contains the 
high-level protocol of Massbus drivers (and much more) through the drive control logic/formatter.  
SI replaces the DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and 
capable of quite long runs.  But it carries much the same low level drive commands.  (Note that 
there's a long history of serializing parallel buses as technology evolves, e.g. PCI -> PCIe 
-> CSI, a.k.a. quickPath). The host ports (UQSSP,KLIPA,etc) replace the registers and DMA 
channels.  Command and function names from Massbus spec & drivers often appear in the MSCP spec 
versions that I used...

Very interesting.  I never thought of MSCP as a descendant of earlier DEC 
storage architectures.  Perhaps because all I really saw was what the UDA50 
exposes, which from the programmer's point of view is radically different from, 
say, the RP04 or RK05.

On the host ports and message based I/O, that same approach appears earlier in 
the KMC11 and its derivatives such as the DMC11 network controller.  Were those 
an influence on the message based host port design?

paul


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

Re: [Simh] Limits on MSCP controllers

[Bob Supnik]

The four ports is not arbitrary. SimH simulates actual hardware. DEC 
never built a backplane MSCP controller with more than four ports.


If you want to extend the current RQ simulator to include third party 
boards (either SMD-based emulators or SCSI-based emulators), feel free 
to add an appropriate mode switch. I don't know what controller ID these 
third party boards returned, though, nor do I know how VMS determined 
the number of ports per controller.


I think it would be better to understand why VMS is waiting to mount 
additional discs. Alternately, just create bigger discs and have fewer 
of them.


/Bob

On 6/23/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

This is, though, another slight silliness in simh. The limit to 4 disks
per controller is very artificial. The UDA50, KDA50, and maybe some
other controllers only have four actual, physical ports, which limited
them to only have four disks per controller. However, MSCP itself do not
have such a limitation, and common SCSI controllers for these machines
which use MSCP allows more than four disks on a controller, and most
software (at least RSX and VMS) also do not limit themselves to only
configure max four disks on a controller. I wish simh didn't put such
arbitrary limitations in. simh also decides on unit numbers by itself,
which could also have been nice to be able to choose.


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

Re: [Simh] simh.trailing-edge.com

[Bob Supnik]

The simh.trailing-edge.com web site is for my personal branch, 3.10; it 
says so, right at the top of the home page.


I have updated the link for FAQ to point to the PDF file and added a 
disclaimer at the top of the help page that this is for 3.10.


/Bob Supnik

On 5/10/2019 11:37 AM, simh-requ...@trailing-edge.com wrote:

Message: 2
Date: Fri, 10 May 2019 11:09:50 -0400
From: Jonathan Welch
To: Mark Pizzolato
Cc: Shane Bouslough,"simh@trailing-edge.com"

Subject: Re: [Simh] FAQ page
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Some cleanup and adjusting needs to be done in regards to these help files.

>From here
http://simh.trailing-edge.com/help.html
There is a link to a missing file
http://simh.trailing-edge.com/simh_faq.txt

Googling simh faq
gives this (not sure if there is a link to it, plus it is out of date)
http://simh.trailing-edge.com/pdf/simh_faq.pdf

Googling simh help
gives this (also out of date)
http://simh.trailing-edge.com/pdf/simh_faq.pdf

Ideally I would like to see the link on the simh help point to the
2019 file mentioned in the previous message but converted to PDF
format.


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

[Simh] VAX physical address space (was: Re: More VAX Simulators)

[Bob Supnik]

If you're talking about the NVAX chip and its derivative systems, 
including the 6600 and 7000, the answer is, no, it doesn't support a 34b 
physical address space. NVAX has a 32b physical address space. Despite a 
25b page frame number (PFNs) in the PTE, the translation buffer has only 
23b for the PFN = 4GB physical address space (see the KA680 Technical 
Manual).


The preferred mode of physical addressing was 32b one-to-one, but a mode 
switch allowed for 30b with sign extension. The Qbus systems, for 
backward compatibility, used 30b with sign extensions and limited the 
physical address space to 1GB (512MB memory, 512MB IO), like in the 
earlier VAX chips.


While NVAX+ was interface compatible with EV4, for interchangeability in 
the 7000, the guts were the same as NVAX, with a 23b PFN.


/Bob

On 4/21/2019 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 5
Date: Sun, 21 Apr 2019 17:04:32 +0200
From: Johnny Billquist
To:simh@trailing-edge.com
Subject: Re: [Simh] More VAX Simulators
Message-ID:<1e40709f-d44c-bb20-4d75-b9442fa38...@softjar.se>
Content-Type: text/plain; charset=utf-8; format=flowed

On 2019-04-21 16:13, Timothy Stark wrote:

Wow!  I try that new simh emulator soon.

Definitely sounds interesting, yes...


Have you try implementing VAX 3100 M96/M98, VAX 4000 M106/M108, and VAX
4000 M90 yet?

How about VAX 66x0 that provides full 32-bit addressing for up to 3.5 GB
main memory?

You know that technically, it supports 34-bit physical addresses, right?
However, I'm not sure DEC ever built any VAX model capable of using it,
nor do I know if VMS supports it.

Virtual address space would still be 32 bits, of course.
And as far as I know, only NVAX supported the 34-bit physical address
space, and it does require changing some registers before the MMU page
address registers go to 25 bits. But it might be that you also need to
go to that mode in order to use 3.5G of physical memory. I can't
remember for sure...

The 66x0 machine I'm pretty sure didn't allow for more than 32-bit
physical addresses. But I'm wondering about the 7000 models...
Not sure if you could even go to 3.5G on the 66x0 machines. The CPU can
do it, but I wonder about the bus structure.

Johnny


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

[Simh] Always a new twist in the VAX

[Bob Supnik]

In implementing the 8200, Matt Burke discovered an IPR (internal 
processor register) that violated the original condition codes 
specification for the VAX.


As originally specified, both MTPR and MFPR set N,Z based on the 
transmitted/received longword data, cleared V, and left C untouched. The 
simulator hardwired this (except for the standardized TBCHK register) 
based on the CVAX microcode.


In the 8200, accessing the RXCD register sets V for character 
sent/received. (The VAX vector MxPRs also return non-standard values for 
the condition codes.) This is one of the reasons that, in 1986, the VAX 
architecture spec was changed to make the condition codes UNPREDICTABLE 
following MTPR or MFPR.


Accordingly, I've added a "hook" to support the 8200 and other 
non-standard MxPRs: global variable mxpr_cc_vc.


At the start of MTPR or MFPR (only), this variable is set to 000C bit>. MTPR will set N and Z based on the transmitted operand and clear 
V and C. MFPR will set N and Z based on the received data and clear V 
and C. Then, at the end, mxpr_cc_vc, masked down to V & C, is ORed into 
the condition codes.


Thus, if an IPR write or read does nothing special, MTPR and MFPR will 
get the canonical results. N,Z set, V cleared, C preserved. However, an 
IPR routine can now specify a non-standard value for V and/or C by 
modifying mxpr_cc_vc.


This tweak required changes only in vax_cpu.c. None of the 
model-specific IPR routines need to be changed, except for Matt's 8200 
RXCD code. Anyone attempting implementation of further models (or VAX 
vectors) should be aware of this new capability.


/Bob Supnik

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

Re: [Simh] VAX 8200/8250

[Bob Supnik]

The 8200 (V11) doesn't have a console processor; the console is 
implemented in microcode (as in the F11/J11) and some macrocode (as in 
MicroVAX II). That's one of the reasons the V11's microstore was 15KW, 
plus a 1 KW patch store, and MicroVAX II's was 1.6KW, with no patch 
store. (The other drivers of V11 microword consumption were the string, 
decimal, and soft floating instructions.) V11 and MicroVAX II have 
essentially identical microwords, although the capabilities of the main 
data path differ slightly, particularly around shifting.


I did not work on the V11 microcode directly. Close to release, when it 
was clear that the patch store would be half empty, I developed a patch 
to optimize CALL/RET using techniques lifted from the 8800 (Nautilus) 
microcode; these were also included in CVAX. I don't have a listing of 
the V11 microcode.


/Bob

On 4/6/2019 6:14 PM, simh-requ...@trailing-edge.com wrote:

Message: 2
Date: Sat, 6 Apr 2019 18:20:37 +0100
From: Matt Burke
To: Simh Trailing-Edge Mailing List
Subject: [Simh] VAX 8200/8250
Message-ID:
Content-Type: text/plain; charset=utf-8

Here is a new simulator for the VAX 8200/8250 systems. Most of the key
features are there including the DWBUA BI-Unibus adapter which allows
all the existing Unibus devices to be used. The console RX50 is also
implemented.

The console processor is not simulated so it uses the same VMB trick as
the VAX-11/7xx simulators i.e. you boot directly from a device "boot
rq0" rather than "boot cpu".

You can get the code from:

https://github.com/9track/simh/tree/vax820

And Windows executable from:

http://www.9track.net/simh/vax820

Please try it out and let me know how you get on.


Matt


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

Re: [Simh] Systems Engineering Labs (SEL) simh simulator available

[Bob Supnik]

Jim,

Congratulations - a great piece of work bringing some distant hardware 
and software back from the Land of the Lost.


/Bob Supnik

On 12/19/2018 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Tue, 18 Dec 2018 21:33:59 -0700
From: "J Bevier"
To:
Subject: [Simh] Systems Engineering Labs (SEL) simh simulator
available
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Hello all,

After about 8 months of work, I am making available a simulator for the SEL 
Concept/32 computers.  Support is provided for 32/27, 32/67, 32/87, and 32/97 
computers.  This initial release uses a test version of the MPX 1.5F operating 
system.


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

Re: [Simh] VAXELN clock

[Bob Supnik]

Sorry I wasn't clear. If you want me to investigate this, I need the 
MicroVAX 3900 environment you mentioned. I didn't write the MicroVAX II 
or rtVAX simulators. I prefer to work with my own code and in my own 
environment (3.10).


Instead, you can just remove the TOY clock attach in your 3900 
environment and check what happens. That will turn off "OS agnostic mode."


/Bob

On 12/16/2018 3:31 AM, simh-requ...@trailing-edge.com wrote:

Message: 5
Date: Sun, 16 Dec 2018 09:24:56 +0100
From: Wilm Boerhout
To:simh@trailing-edge.com
Subject: Re: [Simh] VAXELN clock
Message-ID:
Content-Type: text/plain; charset=utf-8; format=flowed

Bob Supnik schreef op 15-12-2018 om 23:44:

[snip]



So I'd like to see what the behavior is  the clock file
attached.

Or you can post a pointer to the disk image you're using, and I'll try
it on 3.10. I saw the ELN kits on 9track.net, but I don't know which
one to use.

/Bob


Files are available as follows:

   * PIRTVX.SYS - downline load image for target rtVAX-1000:
 https://www.dropbox.com/s/1r3626a4t229snt/pirtvx.sys?dl=0
   * VAXELNboot.rd51 - equivalent local boot disk:
 https://www.dropbox.com/s/kkcwltsbwodb4x5/VAXELNboot.rd51?dl=0
   * archiive with both:
 https://www.dropbox.com/s/416l3ryc5tzghhx/pirtvx.zip?dl=0

images have been built with VAXELN V4.6 on VMS 7.3

For testing, I am using the latest simh 4.0 "git pull" on Raspbian
"stretch" Linux 4.14.79-v7+ (Raspberry Pi Debian for ARM)

The zip archive has been composed on Windows.


/Wilm



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

Re: [Simh] VAXELN clock

[Bob Supnik]

My question is... how does the TODR get reset from the value read by the 
ROM to the ELN value with no intervening write? Did it wrap around? 
Seems unlikely; it shouldn't wrap around before next year.


I suspect it's the "OS agnostic mode" that was added in 4.X. According 
to the writeup,

.

This mode is enabled by attaching the TODR to a

battery backup state file for the TOY clock

(i.e. sim> attach TODR TOY_CLOCK). When operating

in OS Agnostic mode, the TODR will initially start

counting from 0 and be adjusted differently when an

OS specifically writes to the TODR. On the first OS

boot with an attached TODR VMS will prompt to set

the time unless the SYSGEN parameter TIMEPROMPTWAIT

is set to 0.

So I'd like to see what the behavior is  the clock file attached.

Or you can post a pointer to the disk image you're using, and I'll try 
it on 3.10. I saw the ELN kits on 9track.net, but I don't know which one 
to use.


/Bob

On 12/15/2018 3:08 PM, simh-requ...@trailing-edge.com wrote:

DBG(1041144)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B84
DBG(7056415)> CLK REG: todr_rd() - TODR=0x132A4
DBG(7056419)> same as above (1 time)
DBG(9598293)> CLK REG: todr_rd() - TODR=0x133F0
DBG(11998428)> CLK REG: todr_rd() - TODR=0x13526
DBG(14398563)> CLK REG: todr_rd() - TODR=0x1365C


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

Re: [Simh] disk file format (rk05)

[Bob Supnik]

As Paul said, disks with fixed-length sectors are represented as 
fixed-length, data-only records.


The IBM 7094 and Honeywell 516 disks have variable length records, and 
the track format includes metadata on record lengths and block 
addresses. The IBM 1401 and 1620 disks include metadata for the block 
addresses, which is not necessarily based on geometry.


/Bob Supnik

On 9/25/2018 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 3
Date: Tue, 25 Sep 2018 09:53:04 -0400
From: Paul Koning
To: Folkert van Heusden
Cc:simh@trailing-edge.com
Subject: Re: [Simh] disk file format (rk05)
Message-ID:<531aa05c-e3a0-4387-8806-b22269e5e...@comcast.net>
Content-Type: text/plain;   charset=us-ascii

Disks are just sectors.  I think that's true generally; if SIMH supported any 
systems with variable length disk blocks something else would be needed, but 
the only system I can think of that does so is the IBM 360.  (Actually, that 
one is much stranger, with its keyed sector feature.)


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

Re: [Simh] DIV with odd R

[Bob Supnik]

SimH mirrors the behavior of the J11.

The J11 uses a pair of indirect register references labeled 'rsrc' and 
'rsrc+1', but as the microcode definitions make clear, rsrc+1 is 
actually rsrc OR 1. So if an odd source register is specified, the 
dividend is two copies of the same register.


/Bob

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

[Simh] Fwd: Re: F-11 information?

[Bob Supnik]

Lost in the mail, I guess...

The only F11 documentation I remain is (may be) paper copies of the 
microcode for CIS chips 4, 5, and 6 (the packed decimal instructions), 
which I wrote.


 Forwarded Message 
Subject:Re: F-11 information?
Date:   Fri, 31 Aug 2018 15:00:57 -0400
From:   Bob Supnik 
To: Christopher Trumbour 



I do not have F-11 specs; it was designed before my time in the Semi Group.

You could try the Computer History Museum in Mountain View, CA, which
has an extensive archive of DEC material.

/Bob

On 8/30/2018 10:05 PM, Christopher Trumbour wrote:

Hello,
I have recently acquired the F-11 CPU (control and data on a single
ceramic DIP) and MMU in a lot on eBay, and I would like to learn more
about the pinouts, timing diagrams, etc. about these, possibly to try
and make my own PDP-11? I found your page on the F-11, but it doesn't
completely answer my questions. Do you happen to have this information
available, or know where I could actually get it?

Thank you very much,
-Christopher Trumbour



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

Re: [Simh] Implementing a floating point math accelerator simulator

[Bob Supnik]

There's an IEEE-compliant floating point simulator in the Alpha code 
base. However, it only implements what Alpha required, in particular:


- No gradual underflow.
- No 80b floating point (not needed to produce IEEE accurate results for 
single- and double-precision).


You might find John Hauser's SoftFloat to be of more interest, as it is 
very general and implements every possible useless goodie of the 
standard as is existed in the 20th century. It does not have the fifth 
rounding mode that was added more recently, but the chips of that era 
wouldn't have it either.


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

[Simh] Another PDP11 "approximation" (was: DMA to IO page)

[Bob Supnik]

The discussion about the peculiarities of accessing the MK11 CSRs shows 
another limitation of SimH for Unibus systems: the Unibus memory space 
part of the address space of an 11/70 simply isn't there. The ReadB/W 
and WriteB/W routines in the CPU are very simple: if it's memory, it's 
in the M array; if it's in the IO page, it's accessed via a device 
dispatch routine. Anything in between is NXM. There's no provision for 
configuring or accessing Unibus memory or, worse yet, "reflecting" a 
Unibus memory space operation back into real memory to get at CSRs. And 
max memory is 4088KB, not 3840KB.


Again, this reflects the Qbus (and specifically, the KDJ11A) origins of 
the PDP11 simulator. In a 22b Qbus system, everything except the last 
8KB is memory space. In fact, a Qbus system can have (electrically) a 
full 4096KB of memory, and DMA devices can access all of it, because 
unless BBS7 is asserted, everything is memory, and the address space is 
flat.


While the 11/70 required a convoluted "reflection" of CSR accesses back 
into memory space, later Unibus maps (like the 11/24 and 11/44) solved 
this problem more simply, by sending IO space addresses out on the 22b 
private memory bus as well as the Unibus. Except for the memory CSRs, 
these addresses are ignored. If the memory bus responds to an IO page 
reference, the Unibus operation is stopped; there is no Unibus NXM. No 
reflection logic is required or implemented. According to the 11/70 
documentation, a later "modification" of the CPU allowed this same 
approach to be used on the 11/70.


So what does this mean, in practice?

- Except for an unmodified 11/70, accessing memory CSRs just requires 
the current IO page dispatch methods. The simulator has no concept of 
"memory bus" vs "Unibus" (or internal registers versus Unibus); anything 
in the IO page is accessed the same way, which is just fine. Of course, 
none of the memory CSRs are implemented anyway.


- Unless there's a use case for Unibus memory on a 22b Unibus system, I 
don't see any point in adding it.


- If you want to improve the fidelity of the simulation a bit, the "4M" 
memory size setting could be adjusted to 3840 vs 4088, for U vs Q, in 
the cpu_set_size routine.


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

Re: [Simh] DMA to IO space

[Bob Supnik]

It's not a quirk, it's a design feature.

The PDP11 simulator didn't start out as a generalized, all-singing, 
all-dancing emulation of all possible PDP11 models; it started as a J11 
and PDP-11/73 simulator - one processor type, one system, Qbus only. In 
the same way, the VAX didn't start out as a generalized emulation of all 
possible VAX models; it started as a CVAX and MV3900 simulator - one 
processor type, one system, Qbus only. These simulator targets were 
chosen because I managed both chip projects and had all the design 
documents, including microcode, for chips and systems.


Both the PDP11 and the VAX got extended for entirely legitimate reasons 
- to run a broader range of software. Getting to early versions of Unix 
meant supporting the PDP-11/45. Getting to early versions of VMS and BSD 
meant supporting the VAX-11/780. In both cases, the peculiarities of the 
Unibus versus the Qbus were not considered. The Unibus was treated as an 
18b version of the Qbus.


As the simulators have been generalized, detailed divergences from how 
the hardware worked - particularly model by model variances - have 
surfaced repeatedly, and the simulators have been refactored 
accordingly. For example, the discovery that the VAXstation code in 
Ultrix violated the SRM but nonetheless worked on a MicroVAX II required 
major surgery on the handling of unaligned references. Unibus DMA to the 
IO page is just another example of model-specific differences that must 
now be accommodated in order to run more code.


Except for models that have been written with complete design 
documentation in hand, simulation of a model always has limits to its 
fidelity. Within the PDP11 family, I'll vouch for the J11. Many of the 
other models are just sketches (think 11/60), really. Within the VAX 
family, I'll vouch for the CVAX/MV3900 and the 11/780. The others are 
adaptations from one of those two bases and may be incomplete or 
incorrect on details.


Mark has a good understanding of what needs to be done. In theory, the 
same modifications need to be retrofitted to the 11/780 and other Unibus 
VAX models, as well as to the KS10, although I don't think they have the 
internal register shielding problem that the PDP-11 does.


/Bob

On 9/6/2018 6:12 PM, simh-requ...@trailing-edge.com wrote:

It seems like a rather unfortunate design quirk in simh.
A real Unibus don't distinguish between the I/O page any anything else.
In fact, from the Unibus point of view, there is no "I/O page". It's a
flat 18-bit address space where everything works the same.

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

[Simh] More on DMA to IO page

[Bob Supnik]

Looking at the DEC ChipKit documentation, it seems fairly clear that a 
device implemented with the DC003/5/6/10/21 series of chips never drives 
BBS7. BBS7 is an input to the address matching logic implemented in the 
DC005, but that's it.


On the other hand, the DEC Standard for the LSI11 bus says that devices 
are allowed to do DMA to the IO page, and that testing with the 
mandatory 'missing words' (the first 8 words are reserved) is a standard 
diagnostic technique for testing the NXM logic on a DMA device.


On the other, other hand, Qbus configuration standards also say that the 
last 8KB of physical address space must not be implemented as memory. So 
if the IO page doesn't respond to DMA requests, then the device will 
 get an NXM, because there's no memory.


I've looked through the available Qbus DMA device schematics (there 
aren't many), and I see no evidence of devices doing the 9b AND to 
detect IO space and assert BBS7. However, many devices use complex gate 
arrays, and who knows what's going on inside them?


So my tentative conclusion stands: the LSI11 bus did not do DMA to IO 
space, even if it was theoretically possible.


Next, chips. I reread the J11 specification. As I thought, there's no 
way to access any of the registers implemented inside the chipset itself 
from outside. The J11 has no "snoop" function.


On the other hand, there is a small space of "system" registers which 
are expected to be implemented, if at all, in the surrounding CPU logic, 
which was always a gate array. I suspect, but can't prove, that the gate 
arrays didn't respond to DMA requests on these registers either, only on 
DMA requests to real memory. That was certainly true of the first J11 
module, the KDJ11A.


Now, as to bus maps. The 11/70 bus map has a jumper-adjustable upper 
limit for what parts of Unibus address space go through the map, and 
what parts are resolved on the Unibus itself. The maximum value is 
76; that is, the IO page can never be mapped to memory. The 11/44 
bus map has a jumper adjustable upper and lower limit of unmapped Unibus 
space in addition to the IO page, which is always off limits. The 11/84 
bus map is similar, but the jumpers have been replaced by configuration 
registers.


So my conclusion is that IO mapped PDP11s (which are, of course, always 
Unibus) do support DMA to IO space, so you could put a GT40 (in theory) 
on a Unibus J11, and it would work.


Okay, here's the bottom line, then.

1. There's no need to support DMA to IO space on Qbus systems. It wasn't 
done.
2. Therefore, the ba limit test can be for the 18b Unibus limit on 
Unibus systems, that is,


if (UNIBUS && (ba >= unibus_io_base_page)) {then read/write IO space}

3. It's still necessary to keep DMA access away from the CPU and system 
registers, with all the hair that implies.


Personally, I like Tim's solution of a private interface between 
consenting devices. That would certainly work for the GT40 and its ROM too.


/Bob






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

[Simh] DMA access to the IO page

[Bob Supnik]

Apparently, the GT40 does this. So... problems.

1. The original simulator I wrote didn't support DMA to IO space. Code 
for this was added in V4, but the code conformed to the internal 
simulator convention that all addresses are 22b wide. This is certainly 
not the case for Unibus DMA devices; those addresses are 18b wide. So 
the V4 code to test for the IO page needs to be bus-type sensitive.


I'm assuming the GT40 either generates 18b addresses via Address 
Extension bits or does the 16b -> 18b conversion itself, including the 
IO page test. The "Unibus" does NOT do the IO page recognition/sign 
extension to 18b. In all Unibus systems, that's done in the CPU.


On Qbus systems, IO page references are distinguished by the assertion 
of BBS7, and only address bits <12:0> matter. Either the CPU or a DMA 
device can assert BBS7, but I don't think the standard Qbus chips ever 
assert BBS7, so I don't think standard Qbus DMA devices can access the 
IO page. I could be wrong on this.


2. More critically, while all IO space addresses are accessible from the 
CPU, not all are accessible from DMA. In particular, internal CPU 
registers are not, at least on the systems I'm familiar with. (And I 
think Unibus map registers aren't either.) CPUs, in general, didn't need 
to monitor DMA activity, except for systems with internal caches, like 
the 11/70. I know for a fact that the F11 and J11 simply ignored DMA 
activity. The cache, if any, was external to the CPU, and it was the 
responsibility of the cache controller to deal with DMA activity.


At the moment, the PDP11 simulator makes no distinction between IO page 
addresses that are CPU-internal vs bus-external. Without this, DMA 
devices can do truly evil things, like overwrite the PSW or memory 
management registers, that they couldn't do on a real system. So a data 
structure needs to be added to distinguish internal from external IO 
space addresses, code needs to be added to distinguish internal DIB 
entries from external, and call flags added to the IO page read/write 
routines to distinguish CPU access from DMA access.


/Bob


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

Re: [Simh] XVM/DOS Kits Lacking PIREX (Paper) Tape

[Bob Supnik]

Baka me. Included the useless init file instead of the pirex.bin file. 
Fixed.


Redownload xvmdos_uc15.zip.

/Bob

On 7/18/2018 8:07 PM, simh-requ...@trailing-edge.com wrote:

Message: 5
Date: Wed, 18 Jul 2018 19:49:15 -0400
From: Christian Gauger-Cosgrove
To: SIMH
Subject: [Simh] XVM/DOS Kits Lacking PIREX (Paper) Tape
Message-ID:

Content-Type: text/plain; charset="UTF-8"

I downloaded both XVM/DOS kits, and neither seems to contain an image
of the PIREX tape.

Anyone know where one can find the "pirex.bin" that the "XVM/DOS for
the UC15" kit seems to be in need of?

Regards,
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] TMXR/UC15 documentation? (Lars Brinkhoff)

[Bob Supnik]

The UC15 is an 11/05 with part of its address space mapped into PDP15 
memory, and a small amount private. It allows bidirectional writes. 
There is also a control link, basically two parallel interfaces tied 
together.


The key difference with the Rubin 10-11 is that the PDP15 does not 
access PDP11 IO space. While it's possible that it worked, the Unibus 
interface only supported DATI and DATO. Without DATOB (and DATIP), some 
IO devices simply wouldn't function correctly. IO was done via Task 
Control Blocks, and the transmission was sychronized on the control 
interface (effectively, properly interlocked).


In the UC15, the PDP11 is unaware of changes made in shared memory by 
the PDP15; it is only aware (via polling) of changes on the control 
link. Memory sharing only applies to "real" memory. IO space is 
invisible to the PDP15.


Aside from this issue, the PDP15/UC15 devotes a process (core) to each 
CPU. That's fine for two; it's rather problematic for nine (KA10 + 8 
PDP11s). The shared memory interface must be within the same physical 
machine; it won't work across a network link.


I finally published the paper on the UC15 design; find it here - 
http://simh.trailing-edge.com/docs/TheDesignoftheSimulatedPDP1576.pdf


/Bob





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

Re: [Simh] UC15 development is done (for now)

[Bob Supnik]

That's how I built the SiCortex simulator - six instances of the Mips 
CPU were executed, round-robin, from within a single thread to assure 
the lock-step behavior that was required.


Tom's implementation accurately represents how the CDC machines were 
built - or at least, how the original 6600 was built. There was only one 
set of logic for the 10? 12? peripheral processors, and it was 
time-sliced in strict round-robin form. One of Chuck Thacker's classic 
designs at Xerox operated the same way; the Alto, perhaps?


I looked fairly carefully at a software threaded model but concluded 
that the numerous name-space collisions between the PDP15 and PDP11 
simulators would make merging them into a single executable too 
invasive. With the multicore/multisimulator approach, the changes to 
both simulators are very modest.


/Bob

On 5/24/2018 8:04 PM, Paul Koning wrote:



On May 18, 2018, at 2:16 PM, Bob Supnik  wrote:

At long last, I've finished testing the PDP15/UC15 combination, and it works well enough 
to run a full XVM/DOS-15 sysgen. I've sent an "RC1" package to Mark fP. or 
trial integration.

The configuration consists of two separate simulators - the PDP15 and a stripped down 
PDP11 called the UC15. It uses the "shared memory" facility that Mark P. 
created for both the shared memory between the PDP15 and the PDP11 and the control link 
state. Getting decent performance requires multiple cores and tight polling, so this 
initial implementation has a number of restrictions: ...

Impressive!

I wonder if there might be some inspiration in Tom Hunter's DtCyber emulator.  
That is also a multi-processor simulation with tightly controlled timing and 
shared memory.  Tom's implementation supports CDC Cyber configurations with 10 
or 20 peripheral processors plus one central processor.  The central processor 
is actually not all that time critical, and I have extended his code (in a 
fork) with dual-CPU support using a separate thread for the other processor.  
That required no special considerations to get the timing right.

But it turns out that near lockstep operation of the PPUs is critical.  At one 
point I tried splitting those into separate threads, but deadstart (system boot) 
fails miserably then.  Tom's answer is straightforward: the simulator is single 
threaded, timeslicing among the individual emulated processors a few cycles at a 
time.  It actually does one PPU cycle for each PPU, then N CPU cycles (for 
configurable N -- 8 or so is typical to mimic the real hardware performance 
ratio).  It's likely that it would still work with M > 1 PPU cycles per 
iteration, but that hasn't been tried as far as I know.

This structure of course means that entry and exit from each processor cycle 
emulation is frequent, which puts a premium on low overhead entry/exit to the 
CPU cycle action.  But it works quite well without requiring multiple processes 
with tight sync between multiple host CPU cores.

DtCyber doesn't have idling (it isn't part of the hardware architecture) though 
it's conceivable something could be constructed that would work on the standard 
Cyber OS.  There isn't a whole lot of push for that.  I made a stab at it but 
the initial attempt wasn't successful and I set it aside for lack of strong 
need.

Anyway... it's open source, and might be worth a look.

paul




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

[Simh] UC15 development is done (for now)

[Bob Supnik]

At long last, I've finished testing the PDP15/UC15 combination, and it 
works well enough to run a full XVM/DOS-15 sysgen. I've sent an "RC1" 
package to Mark fP. or trial integration.


The configuration consists of two separate simulators - the PDP15 and a 
stripped down PDP11 called the UC15. It uses the "shared memory" 
facility that Mark P. created for both the shared memory between the 
PDP15 and the PDP11 and the control link state. Getting decent 
performance requires multiple cores and tight polling, so this initial 
implementation has a number of restrictions:


- Windows and Linux only.
- The host system must have at least two cores or processors.
- The host system needs wall power, because the two simulated processes 
run flat out, without idling.


There are a couple of clear areas for future development:

- Implementation of the 'shmem' simulator library on other host 
platforms (Mac, VMS).
- Augmentation of the shared memory capability with some sort of 
directed interrupt, so that the two simulator processes can sleep/idle 
when nothing is happening. (Specifically, the simulator needs a 'sleep 
until  or ' capability, where the conditions are expiration of the 
sleep timer or receipt of a signal from another process.)
- Identification of the idle loop on the PDP15 side (the PDP11 sits at a 
WAIT instruction).


Solving the idling problem will help make this configuration 'mobile 
friendly,' which its certainly is not at the moment.


When 3.10 is ready to go, I'll post it on the SimH web site, along with 
a design paper about the UC15 configuration, and additional instructions 
for running XVM/DOS-15 in a UC15 configuration.


/Bob Supnik

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

[Simh] Configuration limitations

[Bob Supnik]

SimH's intended purpose was to run historical software in furtherance of 
computer education. It was not intended as a perfectly accurate 
emulation of every detail of every architecture. There are compromises 
in the design to simplify implementation.


One of those, dating back to its progenitor, MIMIC, is the use of PMS 
(processor-memory-switch) notation, which simplifies IO into controller 
and units. It doesn't really support the notion of nested controllers, 
which is what the Massbus actually requires: a Massbus controller (RH) 
connected up to a maximum of eight subcontrollers (for an RP06, the 
DCL), which is turn connected to one (or for tapes, more than one) unit.


Originally, the Massbus devices were modeled as a controller and units 
(the KS10 simulator still does that). That proved unsatisfactory, 
because it required extensive code duplication between the VAX and the 
PDP11, and between Massbus disks and Massbus tapes. So a while back, the 
RH controllers were split out, and a system-specific hack put in place 
to associate the "independent" RP controller with a Massbus channel. The 
RP controller was not restructured as eight independent controllers with 
one unit each. It remained a quasi-standard disk device, with one 
controller and eight units. As a result, the RP can only be associated 
with a single Massbus channel.


The software changes to get "accuracy" are fairly intrusive.

1. Change the RP to be 'n' separate controllers of one unit each.
2. Change the RH controller to allow a different device for each device ID.
3. Allow each separated controller to be assigned to a MB channel 
independently, based on device ID.


Enforcing configuration restrictions (for example, no mixing of disks 
and tapes on the same channel) is yet more work.


A simpler hack would be to replicate the RP controller, allowing for up 
to 16 drives in two strings. Each string could be associated with a 
different MB channel. The 'generalization' of a controller to support 
multiple instances is shown in the MSCP disks and in the RH controller 
itself.


/Bob

On 4/12/2018 4:34 PM, simh-requ...@trailing-edge.com wrote:

But we are far from being true to the original hardware, so trying to
use that as an argument I think is really weak. Or else we should really
allow me to set CSRs arbitrarily when I have several controllers, allow
me to setup two RP06 on different Massbus channels, and so on. That
would be true to the original hardware. And the same with claiming to
not want to do something because DEC didn't provide it, when obviously
3rd party manufacturers did.


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

[Simh] Terminal mux structure(s) (was DZ vs DZV)

[Bob Supnik]

The original DZ emulator was originally written by a contributor. He 
chose a model whereby lines were not explicitly represented by units. In 
fact, even multiple controllers were not explicitly represented. This 
model was followed in some other emulators, such as the DHU/V11 and the 
NOVA QTY.


When I started writing terminal multiplexors, I was working with devices 
that were essentially multiple instances of the same simple interface, 
such as the LT15, DL11, and so on. I chose to have a unit per line, but 
still only one (SIMH-visible) controller. This allowed fine-grained 
granularity over the number of lines. I carried this model over to 
"real" terminal multiplexors on the IBM 7094, SDS systems, and so on.


Both models seem to work or can be made to work. Neither creates a 
SIMH-visible controller per real controller.


With respect to the DZ11/DZV11, I expect it would be possible to 
parameterize the "lines per controller" math and make it U/Q sensitive. 
If the CPU model is changed mid-simulation, there would be significant 
trauma to any running software, but users should realize there will 
trouble if they change a CPU on the fly.


Unless configuration limitations prevent some family of software from 
running, I don't regard the limitations as significant.


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

Re: [Simh] UNIT_RO in simulated units

[Bob Supnik]

Again, the question is whether you want them to be "read only" to the 
device simulator or to SCP itself.


Typically, I've wanted paper-tape readers to respond to DEPOSIT, so that 
I can make changes or corrections to an input file. The "read only" 
nature of a paper-tape reader comes from the device simulator not having 
any code to write to the associated file. If you want to block DEPOSIT, 
then what you suggest is the correct course of action.


/Bob

On 3/25/2018 8:08 PM, Paul Koning wrote:



On Mar 25, 2018, at 7:23 PM, Bob Supnik  wrote:

Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at DETACH. This makes static 
declaration of a unit as UNIT_RO impossible. He has proposed a change to distinguish a 
"static" read-only unit (UNIT_RO set but not UNIT_ROABLE) from the usual 
"dynamic" read-only, set by ATTACH -R or by a unit-specific SET command.

So how does one deal with things like paper tape readers, which are by defition 
read-only?  I've handled that by marking them ROABLE and supplying the R switch 
in the attach handler.

paul




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

[Simh] UNIT_RO in simulated units

[Bob Supnik]

Mark Pizzolato pointed out that UNIT_RO is cleared unconditionally at 
DETACH. This makes static declaration of a unit as UNIT_RO impossible. 
He has proposed a change to distinguish a "static" read-only unit 
(UNIT_RO set but not UNIT_ROABLE) from the usual "dynamic" read-only, 
set by ATTACH -R or by a unit-specific SET command.


I don't have a problem with this, but I wonder if simulator writers are 
using the bit correctly. UNIT_RO was not intended to be a static, 
declarable flag. Rather, it was the dynamic state of the UNIT_ROABLE 
(unit can be set read-only) flag - just as the UNIT_ATT (unit attached) 
flag is the dynamic state of the UNIT_ATTABLE (unit is attachable) flag. 
If UNIT_ROABLE is set, and a unit is attached with switch -R, then the 
associated file is opened as "rb" (read only) rather than "rb+" 
(read/write). An attempt to write data to the file - either from the 
simulator console or the simulated device - will fail. On the other 
hand, if UNIT_RO is set statically, any associated file will be opened 
"rb+" (read/write). While the DEPOSIT command will fail, due to an 
explicit test, simulated devices can still write to the associated file.


In short, static UNIT_RO should not be used as shorthand for a 
write-protect capability; it will, in fact, not prevent writes to an an 
associated file. In general, device-specific write prevention flags 
(likedisk write lock flags) should be implemented in the device 
simulator code. In my disk simulators, you'll often see constructs like 
this:


#define UNIT_WPRT   (UNIT_WLK | UNIT_RO)    /* write 
protected */


if (uptr->flags & UNIT_WPRT) /* test for write locked */
    rlmp |= RLDS_WLK;

where WLK is the device/unit-specific write lock flag. This implements 
write-locking (from a device point of view) while allowing SCP to both 
read AND write the attached file - very useful during debugging.


/Bob





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

Re: [Simh] best way to scan 172 column fanfold 80s printout?

[Bob Supnik]

Zork (Dungeon) for VAX/VMS is available here: 
http://simh.trailing-edge.com/games/dungeon.zip

The sources to Adventure (VAX/VMS version) are also online, as is the MDL 
source for Zork. I have the PDP-11 version of Adventure as well.

/Bob

On 2/11/2018 1:22 PM, simh-requ...@trailing-edge.com wrote:

zork vms is 6 inches thick, it's no wonder i've never tried it...

Dan.


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

Re: [Simh] Crowther's Adventure Game

[Bob Supnik]

SPEAK got banged up a lot during the conversion to the PDP-11, because 
of the difference in word width, but the relevant fragment is:


5    TYPE 2,(LINES(I),I=1,L)
2    FORMAT(' ',36A2)

This is still 1977-78, but the PDP-11 Fortran compilers (both F4 and 
F77) adhered to the 'standard' for FORMAT statements, which required an 
initial carriage-control character. A space (or 1X) meant single space.


VAX FORTRAN allowed for character strings to be treated as subscripted 
arrays, so the final VAX FORTRAN equivalent was:


    TYPE 2,TLINES(TEMP)(1:NBLEN(TLINES(TEMP)))
2    FORMAT(' ',A)

Still has the initial space for carriage control.

So adding '1X,' to the start of the SPEAK FORMAT statement should do the 
trick.


PDP-11 Adventure was built from the Crowther/Woods 350-point version, 
which had hours controls and the like; all of the policy extensions were 
ripped out to fit the game into a 28KW LSI-11 with two single-density 8" 
floppy disks under RT11.


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

Re: [Simh] External bus interface

[Bob Supnik]

Yes, in separate processes. They use shared memory sections to 
communicate - one as main memory, one as control state.


/Bob

On 1/18/2018 12:26 PM, Lars Brinkhoff wrote:

Hello,

Thanks, that's good to know.  It's encouraging that something is
underway.

Are the machines running inside the same process?  I was vaguely
thinking about running machines as separate processes, with some
communication mechanism between them.  Maybe shared memory, maybe
something else.  It wouldn't even have to be SimH in both ends.

But I'll take what I can get!

Best regards,
Lars Brinkhoff



SimH knows nothing of the internal structure of simulators, so I'm
skeptical of a SimH-level solution. However, a simulator-specific
interface can be built.

As an example, I am finishing up the UC15, which is exactly what you
describe - a PDP11 that is connected to the memory of a PDP15 and
controlled via a cross-connected paralllel link. The PDP11 acts as an
IO processor for the PDP15.

I have not solved all the problems. The solution requires a multi-core
(or other kind of SMP) system, with one core per simulator. It
probably depends on in-order writes and strong cache consistency
semantics. And it definitely depends on tight polling, which causes
the cores to run flat out (unsuitable for mobile devices).


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

Re: [Simh] External bus interface

[Bob Supnik]

Lars,

SimH knows nothing of the internal structure of simulators, so I'm 
skeptical of a SimH-level solution. However, a simulator-specific 
interface can be built.


As an example, I am finishing up the UC15, which is exactly what you 
describe - a PDP11 that is connected to the memory of a PDP15 and 
controlled via a cross-connected paralllel link. The PDP11 acts as an IO 
processor for the PDP15.


I have not solved all the problems. The solution requires a multi-core 
(or other kind of SMP) system, with one core per simulator. It probably 
depends on in-order writes and strong cache consistency semantics. And 
it definitely depends on tight polling, which causes the cores to run 
flat out (unsuitable for mobile devices).


Bob

On 1/18/2018 5:29 AM, simh-requ...@trailing-edge.com wrote:

Message: 4
Date: Thu, 18 Jan 2018 10:12:13 +
From: Lars Brinkhoff
To:simh@trailing-edge.com
Subject: [Simh] External bus interface
Message-ID:<7wtvvjearm@junk.nocrew.org>
Content-Type: text/plain

Hello,

I wrote a GitHub issue about this, but maybe it's better to bring it up
for discussion on the mailing list.  So I'll copy the text here:

Richard Cornwell's KA10 simulator is getting ready.  At MIT, there were
PDP-11s connected to the PDP-10 memory and I/O busses.  The 11s acted as
dedicated I/O processors.  Some of us are interested in recreating
configurations similar to this.  For example, MIT-AI had a PDP-11
connected to control a number of graphical terminals called Knight TVs.
And another PDP-11 for CHAOS networking.

To hook up separate simulator processes this way, I suppose there should
be some kind of bus interface for SIMH.  The interface would have to
support memory transfers, interrupt signals, etc.

Would it be feasible to create such a bus interface?

Best regards,
Lars Brinkhoff



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

[Simh] VMS Source Kit end user license agreement

[Bob Supnik]

Does anyone on the mailing list have the end-user license that went with 
a VMS source kit? I have a kit, but I no longer have the license 
document that came with it.


The VMS group would like to get a copy of the license agreement, as 
apparently HP can't find the original master.


Thanks,

/Bob SUpnik

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

Re: [Simh] TE16 errors on VMS 3.0

[Bob Supnik]

The simulated Massbus tape only throws CRC errors if the tape image 
itself is marked with 'record-in-error'. This seems rather unlikely, and 
the TS11 would also choke on the same problem.


For debug, please prepare an archive containing:

1. The VMS 3.0 image you are using, or a pointer to where it can be found.
2. The tape file you are using, or a pointer to where it can be found.
3. A transcript of the session, from simulator startup to the error, 
including the configuration.


Put the archive on a sharing site like Mega or Mediafire and post the 
URL to the mailing list. I'll take a look at what's happening.


/Bob Supnik

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

[Simh] 8600 console is T11 not Pro based

[Bob Supnik]

Found a good block diagram in the Training Print Set. There was a unique 
T11-based CPU that talked to the Cbus on one side and a Qbus on the 
other. Local storage was an RL02.

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

[Simh] Fwd: retargetable assembler

[Bob Supnik]

Guy is looking to build a Whirlwind simulator, eventually.

I don't know of any assemblers like that. All the cross-assemblers I've 
seen are purpose built, nowadays mostly in Python.



 Forwarded Message 
Subject:retargetable assembler
Date:   Fri, 1 Sep 2017 10:38:08 -0400
From:   Guy Fedorkow 
To: Bob Supnik 



hi Bob,
  I'm continuing to explore the Whirlwind world, one tiny step at a time.
  I thought I'd look around for retargetable cross-assemblers and
disassemblers that might work with the machine's instruction set...
this must come up in the simh world...  do you have a favorite package?

  Thanks
/guy fedorkow


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

[Simh] Hacking the VT100

[Bob Supnik]

The expansion capability of the VT100 was used for all kinds of 
interesting purposes.


The T11 (the one-chip micro intended to replace the LSI11 and F11 in 
embedded applications) didn't generate a lot of buzz inside DEC, so the 
team sponsored a "design contest" to spur usage. I'd never done any 
logic design in my life, so I decided to try designing a T11-based 
single board micro on a VT100-compatible expansion board. It had a 
built-in controller for the standard floppies of the day and was 
intended as a lower-cost, faster, and more integrated version of the 
PDT-11/150. A friendly hardware designer corrected the schematics, 
fabricated a breadboard, and got it running, but that's as far as it went.


The T11 sold in very large quantities as embedded controller. It powered 
the Atari "Paper Boy" arcade game and the ubiquitous RQDX3 Qbus MSCP 
controller, among other uses.


/Bob

On 7/21/2017 12:00 PM, simh-requ...@trailing-edge.com wrote:

The VT100 architecture allows expansion boards to intercept the host
communication stream by plugging into the "standard terminal port"
(STP) connector.  This routes signals from the RS-232 (EIA) connector
on the back of the terminal through the STP and then into the UART on
the terminal controller board.  This lets an add-on device intercept
ESC sequences from the host for processing by the add-on device before
they are sent to the VT100.  The add-on device can also generate
responses to the host in the same way.

You can read more about this in Chaper 7 of the VT100 Technical Manual



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

[Simh] ASTLVL

[Bob Supnik]

From page 6-6 of DEC STD 032 (the VAX architecture spec): "Execution of 
MTPR src, #PR$_ASTLVL with src<31:0> GEQU 5 results in UNDEFINED 
behavior. The preferred implementation is to cause a reserved operand 
fault." MicroVAX II, CVAX, and Rigel all conform to the preferred 
behavior, as does the current simulator, which was written from the CVAX 
microcode. NVAX masks to 3b and does not take an exception on a value 
GEQU 5.


The 1982 Architecture Handbook describes ASTLVL as a 3b register, with 
src<31:3> ignored/read as zero, and exceptions taken on values GEQU 5. 
The780 microcode masks the input value to 3b before doing the GEQU 5 test.


So yes, the ASTLVL test needs to be model specific. I'm sending the 
overall fix and updates for CVAX and the 780 to Mark.


I suspect the behavior became undefined when MicroVAX II simplified the 
original test to save a microword. I do not see how the code fragment 
Matt references could work on a MicroVAX II, which was supported under 
4.5. Perhaps the device Matt mentions couldn't exist on a MicroVAX II?


For those who wants the gory details... uVAX, CVAX, and Rigel do an 
unsigned compare on the unmasked src and the constant 5. Carry out means 
reserved operand. Overflow is ignored. So an input of 0x8002 - 
0x0005 (done in the data path as 0x8002 + 0xFFFB) generates 
overflow (ignored) and carry out.


/Bob





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

Re: [Simh] NetBSD 5.1 on MicoVAX 3900 boot error

[Bob Supnik]

You can get a pre-built Windows 32b 3.9 executable without Ethernet (and 
therefore, without needing WinPCap) here: 
http://simh.trailing-edge.com/sources/simhv39-0-exe.zip. It should run 
fine under W10. See if it will boot NetBSD 5.1.


/Bob Supnik

On 4/18/2017 3:53 PM, simh-requ...@trailing-edge.com wrote:

You shouldn't need WinPCAP merely to test if the CD image is bootable.
The point of the boot test exercise is to help determine if the problem is
in NetBSD or due to recent changes to simh.  If changes to simh are at
fault, I'll track it down and fix the problem.


I specifically want to run a 5.x version of NetBSD. I'm pretty sure it did
run on SIMH 3.8-1 on Windows 7 before the upgrade. I need to downgrade a
laptop I have to Win7 in the future and may try that. Until then I'll play
with OpenBSD which doesn't seem to have any problems with SIMH 4.0 beta.

The boot test I'm suggesting will be far less work than setting up another
system.

Let me know.

- Mark


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

[Simh] Reading RT11 images in SimH

[Bob Supnik]

The vax780_fload.c module contains the logic to read from an RT11 floppy 
disk image (RX01 format). It also has a pointer to the larger utility 
that the code was taken from.


   This code is based on the CP/M RT11 utility, which bears the following
   copyrights:

copyright (c) 1980, William C. Colley, III

Rev. 1.2 -- Craig Davenport - Incitec Ltd  (Feb 1984)
  P O Box 140
  Morningside,
  Qld 4170,
  Australia.
 -- Modified for Digital Research C compiler under CP/M-86
 -- Assebmbly language routines added for BIOS calls etc.

   Thanks to Phil Budne for the original adaptation of RT11 to SimH.

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

[Simh] VAX 8200

[Bob Supnik]

There's an almost total lack of 8200 (aka V-11 or Scorpio) documentation 
on the web. I have chip pictures 
(http://simh.trailing-edge.com/semi/v11.html), and I think the chip 
specs (which won't help much) are in my archive at the Computer History 
Museum. Here are some things to be aware of:


1. The 8200, unlike other mid-range VAXes, does not have a console 
microprocessor. There is a basic console implemented in the microcode. 
It can boot a device via "boot block" booting (for example, the console 
floppy). Thus, it's more like the LSI-11/F-11/J-11 chips, which had a 
basic console in the microcode. The MicroVAX family dispensed with 
console processors and console microcode in favor of boot ROMs.


2. The 8200 has a patchable control store. This was used to avoid 
updating the microcode chips (five of them, all VLSI) for every 
microcode bug. When the system was finally stable and shaken out, there 
was enough patch space left to replace the CALL/RET mask processing, 
which initially used the compact-but-slow MicroVAX II algorithm, with a 
more 8800-like version based on case fanouts. This need not be 
simulated, except insofar as boot processing may try to load it.


3. The 8200 floating point chip, which was not optional, is essentially 
the same as the MicroVAX CPU and has the same POLYx bug.


4. The 8200 series was the only VAX to use the BI as a memory bus. In 
the 6000 series, the XMI/XMI+ was the memory bus, and the BI was used 
strictly for IO.


I've written to a colleague who ran the microcode project for V-11 to 
see if he kept any materials, but I'm not holding my breath.

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

Re: [Simh] Software, firmware, and friends

[Bob Supnik]

Well, I didn't have to ask for it, because I had it... ;) Without it, 
though, I could not have gotten the minute differences between the J-11 
and the other PDP-11s correct.


In general, I am no longer a fan of "approximate" simulations. If you 
just use the spec and ignore the implementation, then even if some 
particular test case (VMS Vxyz) works, the next piece of software may 
fail. I've seen this repeatedly - how the initial simulation of the RH 
worked with all DEC operating systems but failed with Unix, because a 
critical screw-up in the interrupt logic wasn't implemented faithfully; 
how the 750 simulation ran VMS but failed with BSD, because the UBA was 
a simple clone of the 780 (it's still wrong in critical aspects, as is 
the RH750); how the MicroVAX II & III/QVSS combo failed with Ultrix, 
because Ultrix cheerfully violates the SRM and the hardware just works. 
I'm still trying to work out the mischief that the SDS 940's tape drive 
perpetrates. The devil is in the details.


In the end, the implementer may choose to abstract the actual 
implementation away. But if he or she doesn't know what the 
implementation actually does - based on software, microcode, schematics, 
and so on - it's more or less a shot in the dark. One reason I never 
wrote additional VAX models, beyond the 780 and CVAX, is that microcode 
is not available for all the other 'big' VAXes (750, 730, 8200, 8600, 
8900, 9000), and key specs, like bus adapters and device controllers, 
not to mention boot firmware, are missing for them as well as the 4000 
and 6000 series.


/Bob

On 3/12/2017 12:00 PM, simh-requ...@trailing-edge.com wrote:

From: Johnny Billquist



Heck, the J11 also have firmware. I haven't seen anyone ask for that
yet. Instead people implement a PDP-11, and try to make it behave like
the J11.


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

[Simh] HSC vs UDA/QDA

[Bob Supnik]

The HSC family offered a superset of capabilities compared to the 
UDA50/QDA50. In particular,


- tape as well as disk support (TMSCP as well as MSCP);
- controller-based disk to tape backups and tape to disk restores;
- controller-based disk to disk duplication;
- controller-based volume shadowing (RAID 1).

UDA50/QDA50 did not support tape drives, disk duplication, or 
controller-based volume shadowing.


HSC supported some data caching; UDA50/QDA50 did not.

/Bob



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

Re: [Simh] Simh Digest, Vol 157, Issue 21

[Bob Supnik]

Sorry, replied to the wrong email.

On 2/22/2017 12:00 PM, simh-requ...@trailing-edge.com wrote:

Send Simh mailing list submissions to
simh@trailing-edge.com

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.trailing-edge.com/mailman/listinfo/simh
or, via email, send a message with subject or body 'help' to
simh-requ...@trailing-edge.com

You can reach the person managing the list at
simh-ow...@trailing-edge.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simh digest..."


Today's Topics:

1. Re:  Sounds (Johnny Billquist)
2. Re:  Sounds (Cory Smelosky)


--

Message: 1
Date: Wed, 22 Feb 2017 00:40:02 +0100
From: Johnny Billquist 
To: simh@trailing-edge.com
Subject: Re: [Simh] Sounds
Message-ID: <3a411ced-f0a9-6b0a-b616-71c2a61cb...@softjar.se>
Content-Type: text/plain; charset=utf-8; format=flowed

On 2017-02-20 23:54, Lars Brinkhoff wrote:

Peter Onion wrote:

For some machine emulations the production of correct sound is an
integral part of the user experience !

https://www.youtube.com/watch?v=WLEFUA11hgs
https://www.youtube.com/watch?v=AIxZ1i8pvZI
https://www.youtube.com/watch?v=3zezUiJ8NI8

Yes!  Yes!

I implore everyone to watch these videos.  The last one is great!

Well, to be honest. If you have a speaker in the computer, it might make
sense to emulate that...

Johnny



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

Re: [Simh] Simh Digest, Vol 157, Issue 21

[Bob Supnik]

Leaving now... a few errands to run on the way.

On 2/22/2017 12:00 PM, simh-requ...@trailing-edge.com wrote:

Send Simh mailing list submissions to
simh@trailing-edge.com

To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.trailing-edge.com/mailman/listinfo/simh
or, via email, send a message with subject or body 'help' to
simh-requ...@trailing-edge.com

You can reach the person managing the list at
simh-ow...@trailing-edge.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simh digest..."


Today's Topics:

1. Re:  Sounds (Johnny Billquist)
2. Re:  Sounds (Cory Smelosky)


--

Message: 1
Date: Wed, 22 Feb 2017 00:40:02 +0100
From: Johnny Billquist 
To: simh@trailing-edge.com
Subject: Re: [Simh] Sounds
Message-ID: <3a411ced-f0a9-6b0a-b616-71c2a61cb...@softjar.se>
Content-Type: text/plain; charset=utf-8; format=flowed

On 2017-02-20 23:54, Lars Brinkhoff wrote:

Peter Onion wrote:

For some machine emulations the production of correct sound is an
integral part of the user experience !

https://www.youtube.com/watch?v=WLEFUA11hgs
https://www.youtube.com/watch?v=AIxZ1i8pvZI
https://www.youtube.com/watch?v=3zezUiJ8NI8

Yes!  Yes!

I implore everyone to watch these videos.  The last one is great!

Well, to be honest. If you have a speaker in the computer, it might make
sense to emulate that...

Johnny



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

Re: [Simh] Single stepping.

[Bob Supnik]

If you do want to use different timing, then global variable sim_step is 
available with the current step count (0 means not stepping) at entry to 
sim_instr. sim_step isn't deliberately global; it just works out that 
way. Further, it is NOT maintained as the step count is counted down. 
Therefore, you need to pick it up on the way into sim_instr and count it 
down yourself. You also need to cancel out the sim_step unit, which will 
stop the simulator prematurely. Again, the cancellation routine is 
global, although that wasn't deliberate either.


extern void sim_cancel_step (void);
extern int32 sim_step;
:
t_stat sim_instr (void)
{
uint32 step_limit = (uint32) sim_step, i;
sim_cancel_step ();
:
for (i = 0; ((step_limit == 0) || (i < step_limit)); i++) {
t_stat r;
r = cpu_one_instr ();
if (r != SCPE_OK)
return r;
:
}
return SCPE_STEP;
}

Converting sim_step to uint32 should quiesce compilers that are fussy 
about integer overflow or wraparound on variable i. Or you can use 64b 
integers.


Passing the step count as an argument would require modifying every 
simulator. There are lots of SCP variables that may be of interest to a 
running simulator; they are declared as globals.


The PDP-10 requires timing by memory reference (or something close to 
it), because infinite indirects and XCT * must be interruptible to 
prevent system lockup. The 7094 seems to run fine with timing by 
instruction.


/Bob

On 1/30/2017 5:33 AM, Rich Cornwell wrote:

  I track memory cycles so that I/O is closer to the time that the CPU
  expects. This is more important for the I7000 series since
  instructions where executed during I/O and some of the code relies on
  how many instructions can be executed during a read/write. Also for
  some cases during the I7090 I decrement sim_interval during long
  instructions to closer simulate the real speed of the machine.

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

[Simh] Looking for a RIM10B paper-tape image

[Bob Supnik]

Recently, Lars Brinkhoff demonstrated that ITS RIM format was different 
from DEC's RIM10B format and wouldn't load via the LOAD command. In 
adding the capability, I found that the RIM loader was broken for RIM10B 
too. I've fixed it, but I have been unable to test it, for lack of a 
suitable paper-tape image. It's possible to assemble a test program in 
Macro using the RIM10B pseudo-op, but the KS10 simulator doesn't have a 
paper-tape punch for exporting the file in the proper format.


If anyone has a RIM10B paper-tape image I can try, please post it to a 
file sharing site and send me a pointer.


Thanks,

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

Re: [Simh] TSS-8 and ETOS free-redistribution licenses (PDP-8, operating systems)

[Bob Supnik]

ETOS was not a DEC product. I don't know what its terms and conditions are.

DEC made all its PDP8 and PDP15 software into freeware at some point, 
after the last systems had been out of production for years and years, 
but I have no idea where there is any supporting paperwork.


On 1/14/2017 12:00 PM, simh-requ...@trailing-edge.com wrote:

Subject:


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

Re: [Simh] Simulator accuracy (was Re: New TC11)

[Bob Supnik]

Simulators should never fix "bugs". The question at issue is how deeply 
to mimic them, in order to assure maximum compatibility with software.


Over the years, I've concluded that straying too far from the hardware 
is dangerous. I'm not suggesting that every register-transfer-level 
interaction has to be there. It's okay to write


IR = M[PC];

instead of

MA = PC;
ReadM ();
IR = MB;

But software often depends on "bugs". The routines that identify the 
models of a PDP8 and a PDP11 are very dependent on 'bugs' (or 
incompatibilities, if you prefer) between models. (And some of those 
incompatibilities are indeed bugs, like the ASH/ASHC problem in the 
J11.) The IBM 709X's double precision floating point divide is clearly 
rather inaccurate, but the simulator has to reproduce the hardware 
algorithm bit for bit, rather than perform a modern divide.


Fixing, of if you prefer, improving, the way the hardware actually 
worked is hazardous. In the original H316/H516 teletype code, I included 
lots of rational checks to prevent switching the half-duplex interface 
between input and output in "wrong" places. The actual logic had none of 
those checks, and the checks broke the Teletype code in the IMP simulator.


/Bob

On 12/6/2016 5:02 PM, Pontus Pihlgren wrote:

I wonder if I made that sentence more confusing that necessary. I meant
to write:

Are you suggesting that simulators should fix "bugs"?

For someone using a simulator for comparison when restoring real
hardware it could be very confusing.

/P



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

[Simh] Simulator accuracy (was Re: New TC11)

[Bob Supnik]

I'm not sure there are any "non-quirky" standard operating conditions, 
unless they were unpredictable from system to system. For example, the 
implementation of interrupts on the RH series Massbus adapters is truly 
broken, but it has to be simulated accurately, or the workaround in the 
Unix driver fails. (I wrote a short paper on this.) The "unimplemented" 
opcodes in the H316/H516 need to be simulated correctly because some of 
them got used after programmers discovered what they did. For that 
matter, my former colleagues at Unisys got burned when it turned out 
than an "unpredictable" operation had had predictable results for 
several generations of systems, and customer code depended on that.


But perhaps erroneous error responses don't need to be accurately 
simulated. Rigel (the VAX chip used in the VAX6000-400) had a microcode 
bug that failed to fault on a specific reserved operand in INSV. Because 
every other VAX would simply crash the user's program in this case, the 
bug was waived and never fixed. It's hard to see how Paul's example 
could be exploited either.


It is not at all farfetched to use a simulator as part of a historical 
restoration. When my friend in Australia was restoring a classic 8, he 
used the PDP8 simulator to construct and prove out small diagnostics for 
tracing specific logic paths. The 1401 restoration team at the Computer 
History Museum used the simulator as an aid in their work, although any 
discrepancy in behavior must be accounted for (and fixed in the 
simulator, if verified from the schematics).


On 12/6/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Mon, 5 Dec 2016 12:05:39 -0500
From: Paul Koning 



This makes me wonder about the fuzzy line between quirky features and sort-of-bugs.  The code 
snippet you mentioned sounds like it falls on the side of the "quirky", and it sounds 
right for the simulator to implement that.  On the other hand, there's one I recently read about a 
machine in which a subroutine call instruction would fail with the stack pointer equal to -0, but 
when the stack pointer was +0 it would produce an address error only for some of the addressing 
modes.  "The schematics ... confirm this; the reason is unknown" says the article.  
Implementing that sort of corner case is obviously doable, but not necessarily all that useful.

paul



--

Message: 2
Date: Tue, 6 Dec 2016 17:12:00 +0100
From: Pontus Pihlgren 



Are you suggesting that simulators should fix "bugs" for someone using a
simulator for comparison when restoring real hardware it could be very
confusing.

(not that such comparisons should be truated anyway)

/P


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

[Simh] New TC11

[Bob Supnik]

Josh Dersch at the Living Computer Museum found a snippet of real 
DECtape code (that runs on a real 11/40) which fails on the simulator. 
After looking at the snippet, and at the TC11 schematics, I realized 
that the TC11 simulator had a basic design problem. The TC11 is not, in 
fact, a "typical" PDP11 peripheral, where all actions are kicked off by 
setting the "GO" bit (bit<0>). Instead, like every other DECtape 
controller, actions are kicked off by writes to the command register. 
The TC11 "GO" bit (called "DO" in the documentation) has an orthogonal 
role - clearing DONE (READY) and the error flops - but the TC11 is happy 
to initiate actions even if "GO" is not set. I've rewritten the 
simulator to accurately reflect the schematics.


This leads me to think that there's a second principle to bear in mind 
when simulating older machines. The first is "economy of gates". In 
early systems, gates were precious, and the hardware tended to implement 
no more than the minimum functionality required. Error checks were a 
luxury and were often omitted. (This frugality disappeared as more and 
more LSI and MLSI circuits were used.) Examples include the lack of 
checks in switching between input and output on the H316 Teletype 
controller; and the lack of error checks in the 11/750 implementation of 
the UBA.


The second is "economy of design". Within DEC, in the early days when 
resources were scarce, groups freely lifted pieces of designs from each 
other. Thus, the TC11 - a relatively complex controller for its day - 
looks a whole lot more like the 18b TC15 and the 12b TC02 (which 
strongly resemble each other) than it does like a "standard" PDP11 
peripheral. It's as though the core of the other DECtape controllers was 
retrofitted with a new interface to the Unibus, and the guts were left 
alone. Fixing the TC11 simulator was more about stripping  "PDP11" 
thinknig than it was about writing new code.


I think that principle applies elsewhere. If you want to understand the 
DECtape controller for the KA10, look at its near contemporary, the Type 
555 used on the PDP7. The "RB09" disk on the famous PDP7 Unix machine is 
the same drive, and a very similar controller, to the contemporaneous 
RC10. In the 60s and early 70s, DEC didn't have the resources to do 
everything from scratch. That changed, of course, by the mid to late 
70s, when the company had grown substantially.


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

Re: [Simh] TOPS-20 4.1 Cobol 12c Sample test failure

[Bob Supnik]

It is. Great detective work. Thanks.

/Bob Supnik

On 11/5/2016 5:15 AM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Fri, 4 Nov 2016 20:52:33 -0700
From: Pascal Parent
To:simh@trailing-edge.com
Subject: Re: [Simh] TOPS-20 4.1 Cobol 12c Sample test failure
Message-ID:

Content-Type: text/plain; charset="utf-8"

The problem is with this machine intruction:

EXTEND 11(13b8) = CVTBDT convert binary to decimal translated

The processor reference manual states:

*If the instruction is CVTBDT, for the digit substitute a byte from the*
*right half of location E1+D in the translation table, where D is the*
*value of the digit, unless this is the last digit in the conversion, in
which*
*case make the substitution from the right half of the location if M is 0,*
*but from the left half if M is 1.*

However, for the last digit the emulator checks the L bit instead of the M.

The fix in pdp10_xtnd.c is:

308c308
< if ((i == 1) && (AC(p3) & XT_LFLG))
---

> if ((i == 1) && (AC(p3) & XT_MFLG))

I hope this is correct. The CBL74T test completes successfully with this
change.

Pascal.


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

[Simh] State of the 940

[Bob Supnik]

Mark,

Dave Bryan and I are trying to work out the kinks in the 'erase' 
function on the 940, which is needed to make the tape file system work. 
Dave has implemented precise in-place erase for records, but we'll need 
a precise erase for file marks too. And then the whole thing has to be 
tested.


I'll keep you posted on progress.

/Bob

On 10/24/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

Message: 2
Date: Mon, 24 Oct 2016 10:48:44 -0500
From: Mark Emmer
To:simh@trailing-edge.com
Subject: Re: [Simh] Operating Systems with Sources
Message-ID:<4c6e802c-49a7-0680-c8e1-d0253b0d1...@snobol4.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Sorry Al, but I've been pedal-to-the-metal for the past 15 months on
another project and haven't been able to get back to the 940 timesharing
system.  I think the last status I reported was that it was running in
the original build configuration of mag tape and drum, with the ability
to re-assemble, link and run a new O/S from source files.  File I/O to
the drum worked, but the tape-based file system (including
overwrite-in-place) is a disaster that I'm avoiding.  I can't even get
it to recognize when I think is a properly labeled tape, and the new
tape utility is absent.  Best hope is to get the Data Products or Bryant
disk driver working and build a proper disk-based system.
Unfortunately, the Oper utility to layout a disk with file directories
and boot images is missing, so I'm going to have to cobble up something
in C to replicate it.

I do intend to work on it again when programming becomes fun again.

Mark


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

[Simh] Operating Systems with Sources

[Bob Supnik]

I know of at least the following additional assembly language operating 
systems that have sources, mostly on Bitsavers:


1. OS/8 - PDP-8 assembly language
2. XVM/DOS-15 - PDP-15 assembly language
3. CAPS-11 - PDP-11 assembly language
4. TSS/8 - PDP-8 assembly language
5. ADSS-9/15 - PDP-9/15 assembly language
6. RSX11C - PDP-11 assembly language
7. XVM/RSX-15 - PDP-15 assembly language
8. IBSYS - IBM 7094 assembly language
9. CTSS - IBM 7094 assembly language
10. OS/32 - Interdata 32b assembly language
11. SDS940 timesharing - SDS 940 assembly language
12. ITS - PDP-10 assembly language

Not in assembly language, but quite compact, is an early version of 
Burroughs MCP for the B5500, which runs on the various B5500 simulators.


/Bob



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

Re: [Simh] 1401 and arm processors

[Bob Supnik]

It works on the current 3.X build under Windows.

Have you verified that it works on 4.0 on an x86?

On 10/17/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

Re:  1401 and arm processors (Mark Pizzolato)


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

Re: [Simh] Older Model VAX simulators, what can you do with them, and how

[Bob Supnik]

Another issue with the 750, 730, and 8600 is that they are not as exact 
at the 780 and CVAX simulators, because certain critical documents 
(microcode, some subsystem specifications, some schematics) are not 
available. For example, the 750's simulated Massbus and Unibus adapters 
started out as clones of the 780s and have received only minimal 
modifications. Both simulated versions contain  logic and 
error checking; the 750 was done with 400 gate TTL gate arrays, and 
gates were precious. VMS is not sensitive to the remaining differences; 
other operating environments might be. (For example, the 750 didn't 
check that register accesses were longword and aligned, and this was 
used in both the 750 boot ROMs and the diagnostic supervisor.)


For the 750, the UBA750 spec is online (although the register 
descriptions in it are obscure). The RH750 register secs can be inferred 
from the Emulex workalike, the SC750.


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

[Simh] More KL8As

[Bob Supnik]

Per the earlier discussion, I have modified the PDP8's additional 
terminal capability to support 16 lines. I'm testing it now and will 
upload it when it has been wrung out.


In an earlier post, I provided a list of device numbers. The last (16th 
device) was incorrect. The table should be:


#define DEV_TTI1040
#define DEV_TTO1041
#define DEV_TTI2042
#define DEV_TTO2043
#define DEV_TTI3044
#define DEV_TTO3045
#define DEV_TTI4046
#define DEV_TTO4047
#define DEV_TTI5034
#define DEV_TTO5035
#define DEV_TTI6011
#define DEV_TTO6012
#define DEV_TTI7030
#define DEV_TTO7031
#define DEV_TTI8032
#define DEV_TTO8033
#define DEV_TTI9050
#define DEV_TTO9051
#define DEV_TTI10   052
#define DEV_TTO10   053
#define DEV_TTI11   054
#define DEV_TTO11   055 /* conflict: FPP */
#define DEV_TTI12   056 /* conflict: FPP */
#define DEV_TTO12   057
#define DEV_TTI13   070 /* conflict: CT, 
MT */

#define DEV_TTO13   071
#define DEV_TTI14   036 /* conflict: TSC */
#define DEV_TTO14   037
#define DEV_TTI15   072
#define DEV_TTO15   073
#define DEV_TTI16   006
#define DEV_TTO16   007

The revised multiplexer will support a variable number of lines (1-16), 
rather than a fixed number. The default is still 4.


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

[Simh] PDP-8: The possibilities?

[Bob Supnik]

The PDP-5 is, in fact, not all that compatible, because it used memory 
location 0 as the PC, pushing the interrupt locations to 1/2, instead of 
0/1. So any program requiring interrupts will not work on a -5 vs an -8. 
The PDP-5 had an IO halt/restart facility, modeled on the PDP-1 and 
dropped from the PDP-8, which allowed an IOT to "wait" for completion 
without looping and testing a flag. It does not seem to have supported 
an EAE or extended memory.


The PDP-8 family (8, 8/S, 8/I and variants, 8/E and variants, 8/A) are 
superset compatible for defined operations. It's possible to tell them 
apart based on their behavior on undefined operations. The code for 
identifying a PDP-8 is out there, but I don't have it at hand. I 
remember that the behavior of RAL RAR and RTL RTR was one way of telling 
the 8, 8/S, and 8/I apart.


Most of the work for supporting models would be in the peripherals, 
particularly the ones that are 'compatible' across the line (reader, 
punch, terminals, clock). The pre-Omnibus machines used the older style 
IOP1, IOP2, IOP4 pulse methodology; the Omnibus machines can decode all 
8 possible combinations. Beyond that, peripherals tended to be distinct: 
the RK8 for the 8/I vs the RK8E for the Omnibus machines; the Type 552 
DECtape controller for the -5 and -8 vs the TC01/TC08 for the later 
machines.


The "CMOS 8s" are a whole different kettle of fish. They were only used 
in word processing/DECmate systems and had many unique features.


/Bob

On 9/8/2016 9:10 PM, simh-requ...@trailing-edge.com wrote:

Message: 1
Date: Thu, 8 Sep 2016 18:57:52 -0400
From: Ray Jewhurst
To: simh
Subject: [Simh] PDP-8: The possibilities?
Message-ID:

Content-Type: text/plain; charset="utf-8"

After both reading and participating in some recent discussions, I got to
thinking that maybe the array of PDP-8 models could be better represented.
I say this because from what I have read very early PDP-8 code is not  100%
compatible with later models conversely the PDP-5 is compatible with the
early code and likewise uses a negibus like the Straight-8. I thank this
could be a rewarding experience for some of us and since I can't work I
would be able to help coordinate, write pseudo code and beta test. If
anyone is interested in this let the discussion begin.

Thanks
Ray


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

Re: [Simh] KL8-JA (Bob Supnik)

[Bob Supnik]

More limitations: the PDP8 interrupts are laid out in a single 32b word. 
There isn't room to have an additional 12*2 = 24 interrupts; the word is 
almost full.


If anyone wants to try this, I suggest looking at the PDP15 
implementation, which supports 16 (or more) lines. It already has the 
mechanisms needed, including use of a subroutine to map the IOT to a 
line number, multiplexing all of the separate interrupts onto a master 
input and a master output interrupt, and the code for varying the number 
of lines. The PDP8 core will still need an extension to the DIB 
mechanism, perhaps an optional "callout" to a configuration routine that 
would fill in IO dispatches as it saw fit, rather than algorithmically 
based on the DIB itself; and the PDP8 would need a more flexible, table 
lookup based mapping algorithm from device number to line number.


/Bob

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

Re: [Simh] KL8-JA

[Bob Supnik]

Yeah, sorry.  It is a single line. The simulator treats all of them as a 
single device.


The limit of 4 lines comes from the (current) limit of 8 device 
addresses per device (in pdp8_defs.h). Further, the simulator assumes 
that the device addresses within a device are contiguous, and the 
additional serial lines use contiguous device addresses. It maps device 
# to line # as follows:


line # = (device # - base) / 2

This algorithm dates back to the PDP8/I and is documented in the 1970 
Small Computer Handbook.


According to the TSS documentation, up to 32 lines were supported. 
Clearly, they could not all be PT08s/KL8s, because that would use up 
every IO device number in the PDP8. According to the TSS/8 source I 
have, provision was made for 16 PT08/KL8s, with device number 
assignments as follows:


IFZERO DC08A <
KSKIP+400/K01/KEYBOARD SKIP IOTS FOR PT08 AND KL8E
KSKIP+420/K02
KSKIP+440/K03
KSKIP+460>/K04
KSKIP+340/K05; K01 IF DC08A WITH PT08'S
KSKIP+110/K06; K02 IF DC08A WITH PT08'S
IFNZRO CPU-1 <
KSKIP+300>/K07; K03 IF DC08A WITH PT08'S
KSKIP+320/K10; K04 IF DC08A WITH PT08'S
KSKIP+500/K11; K05 IF DC08A WITH PT08'S
KSKIP+520/K12; K06 IF DC08A WITH PT08'S
KSKIP+540/K13; K07 IF DC08A WITH PT08'S
KSKIP+560/K14; K10 IF DC08A WITH PT08'S
KSKIP+700/K15
KSKIP+360/K16
KSKIP+720/K17
KSKIP+060/K20
KSKIP+140/K21
KSKIP+160/K22
KSKIP+050/K23

IFZERO DC08A <
TSKIP+410/K01/TELEPRINTER SKIP IOTS FOR PT08 AND KL8E
TSKIP+430/K02
TSKIP+450/K03
TSKIP+470>/K04
TSKIP+350/K05; K01 IF DC08A WITH PT08'S
TSKIP+120/K06; K02 IF DC08A WITH PT08'S
IFNZRO CPU-1 <
TSKIP+310>/K07; K03 IF DC08A WITH PT08'S
TSKIP+330/K10; K04 IF DC08A WITH PT08'S
TSKIP+510/K11; K05 IF DC08A WITH PT08'S
TSKIP+530/K12; K06 IF DC08A WITH PT08'S
TSKIP+550/K13; K07 IF DC08A WITH PT08'S
TSKIP+570/K14; K10 IF DC08A WITH PT08'S
TSKIP+710/K15
TSKIP+370/K16
TSKIP+730/K17
TSKIP+070/K20
TSKIP+150/K21
TSKIP+170/K22
TSKIP+650/K23

The device number conflicts in this table are at least the following:

cassette/magtape (70)
TSC timesharing option (36)
floating point processor (55)

None of these are supported in TSS/8.

Bottom line: with some very significant surgery on the PDP8 simulator's 
core structures (DIB definition and IO device allocation) and a much 
more flexible device # -> line # algorithm in the KL8 simulator, it 
would be possible to extend the PDP8 to 16 additional lines. I don't see 
the point, but that's just my view.


/Bob




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

Re: [Simh] Pdp8 terminals

[Bob Supnik]

The PDP8 simulator is more or less a PDP8/A, and its terminal 
"multiplexor" is a KL8-JA, which implements four discrete KL8A style 
interfaces. These are superset compatible with the PDP8/I's PT08 
discrete interfaces, and thus TSS/8 will work. Note that TSS/8 supports 
only four discrete terminal interfaces. To get more than four lines, the 
configuration must have a DC08(A), a multiplexor for the PDP8/I. The 
DC08(A) is not implemented at the moment.


There was a significant evolution in the PDP8 family's IO controllers 
from the original 8 and 8/I to the Omnibus-based 8/E and 8/A. The 
original DECtape controller for the PDP8 was a single-cycle data break 
device; the later TC01 and TC08 were three-cycle data break devices. The 
original RK controller for the 8/I was very different from the later 
RK8E. In general, peripherals unique to the 8 and 8/I, such as the 
DC08(A), are not implemented.


/Bob

On 9/6/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

Pdp8 terminals (Gene Irwin)


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

Re: [Simh] Interdata OS/32 question

[Bob Supnik]

You can override the default value of delete with

SET CONSOLE DEL=interpret ASCII code value as DELETE

The value is radix 16 on hex machines, and radix 8 on everything else.

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

[Simh] PDP paper tape reader end of file conditions

[Bob Supnik]

DEC didn't make much investment in error detection for its paper tape 
equipment. In the 18b family, the PDP-9 was the first 18-bit system to 
feature a "reader empty" flag. The PDP-8 never had one. (The PDP-11 had 
one from the get go.)


That begs the question of what these early PDP's did when they ran out 
of tape. The reader logic was very simple; when the reader saw a 0->1 
(dark to light) transition on the feed hole, it strobed a character. So 
there might be a last garbage character when the tape ran out, but after 
that, the feed hole always saw light, and there would be no further 
transitions.


Some drivers used timing loops or the clock to "time out" the reader. 
The readers ran at 300cps, so if say 10-20ms went by without a 
character, end of tape was a good guess. Another strategy was to 
"guarantee" or require some sort of end of input marker on the tape. For 
example, hardware read-in mode terminated when it detected a punch in 
channel 7.


The PDP-1 presents different problems because it has IO modes that are 
absent from later PDPs - synchronous and asynchronous wait. These 
allowed programmers to issue a read and then stall (immediately or 
later) until a character was ready. The problem, of course, is what 
would happen if the reader ran out of tape in these modes. My best guess 
is that the PDP-1 would stall until reset.


This came up during debug of Expensive Typewriter, the PDP-1's editor. 
If an input tape isn't properly formatted and runs off the end, ET hangs 
up in an indefinite stall. When ET writes its output to tape (via p), 
users must give another command at the end (s) to write the appropriate 
end of tape marker.


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

Re: [Simh] Ferranti Pegasus Simulator

[Bob Supnik]

There are any number of strange-length divide algorithms in SimH. Here 
is the PDP-10 code for dividing a 70b unsigned integer by a 35b 
(unsigned) integer.


// dvd[0:1] = 70b dividend, high order first (35b in each word)
// dvr = 35b divisor
// rs[0:1] = quotient remainder
// all variables (except i)  are unsigned 64b

for (i = 0, rs[0] = 0; i < 35; i++) {   /* 35 quotient 
bits */

dvd[0] = (dvd[0] << 1) | ((dvd[1] >> 34) & 1);
dvd[1] = (dvd[1] << 1) & MMASK; /* shift 
dividend and mask */
rs[0] = rs[0] << 1; /* shift 
quotient */
if (dvd[0] >= dvr) {/* subtract 
work? */

dvd[0] = dvd[0] - dvr;  /* quo bit is 1 */
rs[0] = rs[0] + 1;
}
}
rs[1] = dvd[0]; /* store 
remainder */


It's easy enough to see how to expand this to a computer with 39b in 
each word of dvd - just increase the loop count from 35 to 39, increase 
the shift count in the second line from 34 to 38, and define MMASK to be 
39 bits of 1s.


In general, it's simplest to implement this sort of multi-precision 
divide unsigned. Simply calculate the sign of the quotient and dividend 
before starting (quo sign = dividend sign XOR divisor sign; rem sign = 
dividend sign), then take the absolute value of dividend and divisor 
before running the bit-by-bit loop; fix up the signs of quotient and 
remainder when done.


This assumes that the Ferranti did a precise divide. That's not 
necessarily the case. The IBM 7094 approximated double precision 
floating divide with a two term Taylor-series expansion...


I hope the available Pegasus documentation provides sufficient detail on 
how divide was actually implemented.


/Bob

On 6/10/2016 8:15 PM, simh-requ...@trailing-edge.com wrote:

--

Message: 1
Date: Sat, 11 Jun 2016 00:46:02 +0100
From: "Dave Wade"
To:
Subject: [Simh] Ferranti Pegasus Simulator
Message-ID:<002401d1c372$3fc331e0$bf4995a0$@gmail.com>
Content-Type: text/plain; charset="utf-8"

Whilst its not a SIMH simulator, I hope you can help. I want to write an
emulator for the Pegasus. The Ferranti Pegasus was (there are none operating
at present) a strange beast with two 18-bit instructions per 39-bit word.
Generally, it does 39-bit twos complement arithmetic. The multiply results
in a 77-bit result which I have no problems implementing.
  
Where I am struggling is with the divide. I need to be able to divide a

77-bit number by a 39-bit number and get a 39 bit quotient and a 39 bit
remainder. As the compiler I am using only does 64-bit numbers this is
proving challenging. Any one got a good article on how to do this?
  
Dave Wade

G4UGM


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

Re: [Simh] Using the simh LGP-30 emulator

[Bob Supnik]

A really valuable tutorial. It's also the first proof that the LGP30 
simulator sort-of works; I'm relieved.


Shoehorning the LGP30's operating procedures into SimH's default syntax 
was difficult. It might have been better to use the 'simulator-defined 
command' capability to  create a set of LGP30 specific commands. But 
there isn't much user interest in this ancient beast, so I'd as soon let 
sleeping dogs lie.


/Bob

On 6/10/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

 Forwarded Message 
Subject: Using the simh LGP-30 emulator
Date: Fri, 10 Jun 2016 01:04:56 +0200
From: Oscar Vermeulen
Reply-To: General Discussion: On-Topic and Off-Topic 
Posts
To:cct...@classiccmp.org  

Some time ago, there were two posts asking how to operate the simh LGP-30 
emulator. It is not exactly obvious from the
rudimentary manual, and it seems nobody had figured it out completely. I am 
slightly obsessed with this machine at the
moment (it happens), so here is a how-to on operating the emulator and running 
the tape library of Christian Corti on it
- in the hope it's of use to others looking for clues:


http://obsolescenceguaranteed.blogspot.ch/2016/06/using-simh-lgp-30-emulator.html


Corti's LGP-30 emulator, by the way, gives a much better feel for the machine. 
But simh source is available, which I
needed because I'm making a replica hardware front panel for the machine.


Regards,

Oscar.


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

Re: [Simh] Pre-packaged kits

[Bob Supnik]

Please see the SimH web site 
(http://simh.trailing-edge.com/software.html) for examples of kits to 
run on SimH simulators. This works better for simple, stand-alone 
applications that for full operating systems with layered products 
installed, some of which (like VMS) require licenses and media from the 
vendor.


/Bob

On 5/31/2016 12:54 PM, simh-requ...@trailing-edge.com wrote:

--

Message: 1
Date: Tue, 31 May 2016 12:09:13 -0400
From: Ray Jewhurst
To: simh
Subject: [Simh] So far unnamed project
Message-ID:

Content-Type: text/plain; charset="utf-8"

Greetings all

I am a total computer history buff.  I have  only used "real" PCs and Macs,
but through simulation and emulation I have grown to be enamored with many
different types of old computers especially DECs.  I would love to spread
my enthusiasm to the younger generation and I feel that Simh may be one of
the ways to accomplish this. What I would like to do is package various
simulators with pre-built configurations and documentation to show how
these old machines work. I would like to ask all of you for advice and
suggestions to help teach the younger generation how elegantly things used
to be done.

Thanks
Ray


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

Re: [Simh] [SimH] Series/1 (was System/1)

[Bob Supnik]

As several people pointed out, it's Series/1, not System/1. My bad.

Thanks, Al. I look forward to the availability of software. You're quite 
right about the documentation - there's more than enough to write a 
simulator, and it's extremely detailed.


/Bob

On 5/26/2016 8:32 PM, simh-requ...@trailing-edge.com wrote:

--

Message: 8
Date: Thu, 26 May 2016 17:32:21 -0700
From: Al Kossow
To:simh@trailing-edge.com
Subject: Re: [Simh] System/1
Message-ID:<6b6b4eb8-e579-52bf-b9a0-eac443426...@bitsavers.org>
Content-Type: text/plain; charset=utf-8



On 5/26/16 5:29 PM, Al Kossow wrote:

>
>
>On 5/26/16 1:46 PM, Bob Supnik wrote:

>>I didn't know of any surviving software

>
>look on bitsavers for docs and software, unless I forgot to upload it.
>

I just looked, and I haven't put up the floppy images
There is more documentation up than you'd ever care to look at


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

[Simh] System/1

[Bob Supnik]

The DoD system running our nuclear arsenal off floppy disks is an IBM 
System/1, their 1970's "answer" to the popularity of DEC and DG 
minicomputers. When they released it, some IBM flack said that the 
System/1 "legitimized" the minicomputer market. This led to a famous 
(albeit never published) DG ad that said,


*They Say IBM’s Entry Into Minicomputers Will Legitimize The Market.*

*The Bastards Say, Welcome.
*

AFAIK, there's no emulator for the System/1. I've looked at it several 
times, but it's a typical IBM mess - overly complicated for what it's 
supposed to do. I didn't know of any surviving software, either (except 
now DoD's), so there was never any real motivation to work on an 
emulator. Perhaps DoD would like to sponsor one . ;)


/Bob Supnik

**

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

Re: [Simh] Question about card readers.

[Bob Supnik]

There is a proposed card reader library (not mine) in the GitHub 
repository, which you could try.


On the 1401, the handling is as follows:

1. The card reader buffer is 2*CBUFSIZE + 1, where CBUFSIZE is an 
internal SimH constant for buffer size. The buffer is zeroed before a read.
2. The card is read with fgets (buf, CBUFSIZE/2*CBUFSIZE, file), 
depending on whether the data is text or column binary.  This guarantees 
that there is a null at the end of the string, because the buffer is one 
character longer than the maximum read.
3. The card reader then picks up 80/160 characters to process and 
discards the rest.


The 7094 card reader behaves the same way.

So...

If the line is less than 256 characters, it is read in its entirety. Any 
characters beyond 80/160 are discarded.


If the line is 256 characters or more, 255 characters are read. Any 
characters beyond 80/160 are discarded. However, the rest of the line 
will be read by the next "read card".


In general, card lines are expected to be no more than 80 characters 
(text) or 160 characters (column binary). If presented with a long input 
line, the card reader simulator can do what it wants, but I think 
discarding the excess characters is correct.


I'm not in favor of putting metadata into card files. Multiple stackers 
can be implemented by having a separate file for each stacker bin.


In general, card readers were very rare on DEC equipment, and card 
punches even more so - even on PDP-10s.


/Bob

On 5/26/2016 12:00 PM, simh-requ...@trailing-edge.com wrote:

--

Message: 1
Date: Wed, 25 May 2016 18:07:15 -0400
From: Richard Cornwell
To:simh@trailing-edge.com
Subject: [Simh] Question about card readers.
Message-ID: <20160525180715.56de6419@hobbit>
Content-Type: text/plain; charset=US-ASCII

Hello all,

I am asking for feedback on how to handle Punched card input. I am
wondering about how to handle the case of reading a greater then 80
character record on a 80 character punch card. Should characters
beyond the end of the card be truncated, or should they continue on
the next card.

Any ideas?

Rich


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

[Simh] Contributing to SimH

[Bob Supnik]

Christian Gauger-Cosgrove's comment about contributing to SimH triggered a 
thought I'd like to share.

Not surprisingly, there has been a lot of focus on the systems many of us used 
in the past, like the PDP-11 and VAX, and on improving SimH's usability. 
However, the purpose of the project is to preserve historic systems and 
software through simulation. More than 40,000 different computers were designed 
before 2010, and SimH supports a couple of dozen. So anyone can contribute to 
SimH by:

1. Writing a new simulator.
2. Extending an existing simulator with new IO devices or models.
3. Debugging beta simulators that are not fully tested.
4. Debugging software that is available but not tested.

All of these activities tend to be well isolated from the core control package 
and libraries. Writing a new simulator is unlikely to break SimH.

Older machines tend to be simpler to simulate than recent ones, although if you 
go really far back (like the IBM 650), you may run into issues like plugboard 
programming that are difficult to understand, let alone simulate. Old software 
is invariably in assembly language, and if that is out of your comfort zone, 
debugging old software can be problematic.

Some random suggestions:

New simulators: Bendix G15 (software is available); Datacraft/Harris 24b 
systems (software is available); DG 32b systems (software licensing is a 
problem); Prime 16b and 32b systems.

New IO devices or models: KL10 (porting Ken Harrenstein's KLH10 to the SimH 
framework); other IBM 14XX models (for example, the 1440).

Debugging beta simulators: Sigma series.

Debugging software: SDS 940 timesharing; CTSS for the IBM 7094.

I'm quite encouraged by recent developments, such as the HP 3000 simulator, the KA10/KI10 
simulator, and the restoration of Unix "v0" (PDP-7 Unix). But there's always 
more to do.

/Bob Supnik

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

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

[Bob Supnik]

Upstate Medical Center in Syracuse had a number of PDP-15s, including 
XVMs. Some are still be in the hands of a private collector. However, 
that person is unwilling to share materials, particularly software kits, 
from his collection.


If the RP disks follow normal SimH practice, then they are simulated as 
data files, without metadata. A PDP-10 RP would have blocks of 128 x 
36bit words, each word right justified in a 64b container; a PDP-15 RP 
would have blocks of 256 x 18bit words, each right justified in a 32b 
container.  For interchange, the two simulators would have to adapt a 
common container size. Alternately, the disk could be buffered in 
memory, and the format adjusted at attach (as is done with DECtapes).


/Bob

On 5/5/2016 6:01 AM, simh-requ...@trailing-edge.com wrote:
Message: 5 Date: Tue, 15 Mar 2016 20:10:59 -0400 From: Richard 
Cornwell  To: simh@trailing-edge.com Subject: 
Re: [Simh] The lost disk of the PDP-15 Message-ID: 
<20160315201059.25711d9a@hobbit> Content-Type: text/plain; 
charset=US-ASCII 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

>


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