Re: [Simh] EXT : VAX SDL support?

[Jeremy Begg]

Hi,

>I've seen references to VAXwindows.  I know it predates VMS 5 but I am not
>sure if it was a layered product or not.

VAXwindows was a layered product (like just about everything DEC sold for
VMS).  Without it a VAXstation of that era wouldn't be very user friendly,
but it would boot happily enough.  However all my VAX software CD-ROMs are
from V5.3(?) onwards so I very much doubt the VAXwindows product is there.

Jeremy Begg



>On Mar 9, 2017 8:31 PM, "Paul Koning"  wrote:

>>
>> > On Mar 9, 2017, at 7:20 PM, Hittner, David T [US] (MS) <
>> david.hitt...@ngc.com> wrote:
>> >
>> > The Qbus-based VAXen support the QVSS (black-n-white) video module
>> cards, which were the basis of the original VaxStation I and were also
>> compatible with VaxStation II's, III's, and 4000's. The SIMH QVSS uses SDL
>> for visualization.
>> >
>> > This is a native DecWindows interface.
>>
>> The eary VAXstations could also run VAXwindows, which predates DECwindows
>> and isn't based on X.  I used it at one time.  It was ok, but rather slow.
>> It's not a client-server system as X is.  I wonder if any copies of the
>> software still exist.
>>
>> paul
>>
>> ___
>> 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] VAX 82x0/83x0 and VAX 66x0 tech docs (and VAXBI docs)

[Tim Stark]

Folks,

 

I found a few technical reference manuals (KA820/KA825 and VAX 6200 and 6600
series) through google search, etc. 

 

I reviewed KA820/KA825 (VAX 82x0/83x0) tech docs and it does not use SRM
firmware like KA780/KA865 processors. It uses VAXBI interface for I/O
devices. I think that it can be implemented on SIMH emulator easily.  I
heard someone plans to implement VAX 82x0/83x0 for SIMH emulators (on track9
website) but it never happens.

 

I reviewed KA62A (VAX 62x0) and KA66A (VAX 66x0) tech docs and noticed that
VAX 66x0 supports up to 3.5G memory access by using 32-bit addressing mode.
VAX 6000 series is multiprocessing system. 

 

It need SRM firmware to boot system. Does anyone have a copy of KA62A and
KA66A firmware?

 

Does anyone have any tech docs for VAXBI devices like DEBNA Ethernet, etc?
I only found KDB50 user's guide docs that provides KDB50 programming through
VAXBI registers. 

 

NetBSD/vax supports VAXBI devices. 

 

Thanks,

Tim

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

Re: [Simh] EXT : VAX SDL support?

[Ray Jewhurst]

I've seen references to VAXwindows.  I know it predates VMS 5 but I am not
sure if it was a layered product or not. There is also a very primitive
window system for P/OS on the DECPro called Synergy  (which I would love to
find documentation for) that you could control with either the keyboard or
the digitizer. I comes with the P/OS package for xhomer but I have yet to
get it to  work with the mouse-emulated digitizer.

Ray

On Mar 9, 2017 8:31 PM, "Paul Koning"  wrote:


> On Mar 9, 2017, at 7:20 PM, Hittner, David T [US] (MS) <
david.hitt...@ngc.com> wrote:
>
> The Qbus-based VAXen support the QVSS (black-n-white) video module cards,
which were the basis of the original VaxStation I and were also compatible
with VaxStation II's, III's, and 4000's. The SIMH QVSS uses SDL for
visualization.
>
> This is a native DecWindows interface.

The eary VAXstations could also run VAXwindows, which predates DECwindows
and isn't based on X.  I used it at one time.  It was ok, but rather slow.
It's not a client-server system as X is.  I wonder if any copies of the
software still exist.

paul

___
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

Re: [Simh] EXT : VAX SDL support?

[Ray Jewhurst]

I've seen references to VAXwindows.  I know it predates VMS 5 but I am not
sure if it was a layered product or not. There is also a very primitive
window system for P/OS on the DECPro called Synergy  (which I would love to
find documentation for) that you could control with either the keyboard or
the digitizer. I comes with the P/OS package for xhomer but I have yet to
get it to  work with the mouse-emulated digitizer.

Ray

On Mar 9, 2017 8:31 PM, "Paul Koning"  wrote:

>
> > On Mar 9, 2017, at 7:20 PM, Hittner, David T [US] (MS) <
> david.hitt...@ngc.com> wrote:
> >
> > The Qbus-based VAXen support the QVSS (black-n-white) video module
> cards, which were the basis of the original VaxStation I and were also
> compatible with VaxStation II's, III's, and 4000's. The SIMH QVSS uses SDL
> for visualization.
> >
> > This is a native DecWindows interface.
>
> The eary VAXstations could also run VAXwindows, which predates DECwindows
> and isn't based on X.  I used it at one time.  It was ok, but rather slow.
> It's not a client-server system as X is.  I wonder if any copies of the
> software still exist.
>
> paul
>
> ___
> 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] Compiling simh on an Android using Termux

[Ray Jewhurst]

IIRC, someone successfully compiled simh on Android using the Termux shell.
I really don't want to root  my tablet and will be without my computer for
a week or so, so I thought I would play around with some OS configurations,
brush up on my PDP-11 assembly etc. Anyways I am not good with Linux
makefiles and was wondering if anyone could send me the one they used. I
really don't need the whole suite, just the 11, Vax 780 and maybe the 10 or
3900.  Any help would be great!

Thanks

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

Re: [Simh] EXT : VAX SDL support?

[Hittner, David T [US] (MS)]

The Qbus-based VAXen support the QVSS (black-n-white) video module cards, which 
were the basis of the original VaxStation I and were also compatible with 
VaxStation II's, III's, and 4000's. The SIMH QVSS uses SDL for visualization.

This is a native DecWindows interface.

To be honest, it's just as easy to start DecWindows headless on any VAX and 
connect to the headless DecWindows from your PC via X or X over SSH.

Dave

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Sampsa Laine
Sent: Thursday, March 09, 2017 1:43 PM
To: SIMH
Subject: EXT :[Simh] VAX SDL support?

Quick question - I saw SDL graphics support mentioned somewhere and wondered 
which emulators have graphics support? Do any of the VAX ones?

Can I run native DECWindows on any of them?

sampsa


___
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

Re: [Simh] HSC vs UDA/QDA

[Paul Koning]

> On Mar 9, 2017, at 12:15 PM, Mark Pizzolato  wrote:
> 
> On Wednesday, March 8, 2017 at 11:50 PM, Johnny Billquist wrote:
>> ...
> 
> When Matt Burke initially was working on this, I believe that we talked 
> briefly
> about extending sim_ether to support packet delivery across IP multicast.  
> With that model, all of the systems connected to a particular star coupler 
> would use the same multi-cast group.  I think that DEC may have done 
> something very similar to this when they implemented LAVC.  Several 
> independent Local Area VAX Clusters can certainly coexist on the same 
> LAN without interference.

No, LAVC is an Ethernet based protocol (it sits directly on top of Ethernet).  
No routing layer, IP or otherwise.

You could tunnel it over Johnny's bridge protocol, of course.

paul


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

Re: [Simh] CI750 tech docs and VAX firmware

[Johnny Billquist]

On 2017-03-09 19:00, Paul Koning wrote:



On Mar 9, 2017, at 12:27 PM, Timothe Litt  wrote:

..
With respect to an earlier question about CI emulation:  The best approach may 
be to emulate it as multicast ethernet.  Setup a couple of groups for each star 
coupler.  Each coupler supports up to 32 nodes.  For VMS, half o them hosts, 
half storage.  CI is a 50Mb/s (might be 70, but I remember 50 from the initial 
doc) CSMA/CD bus.


70 Mb/s is the number I always saw.


Me too.


 The cabling is redundant (A & B cables), so assign one MC group to each per 
star.  (Yes, there are DECnet drivers for on multiple OSs.  I think it was 
considered a multipoint medium with addresses related to (CI) node numbers rather 
than an ethernet (broadcast) - but it's been a while.)


I don't think DECnet ever supported CI.  It certainly doesn't show up in the 
DECnet architecture specs anywhere.


It did support it. But if I remember right, it was kindof not really 
supported. The drivers existed, and was provided to customers, but I 
think VMS manuals mentioned it as some unsupported lines. I remember 
having tested it a little, and did get it to work.


Under Ultrix I also managed to get TCP/IP running over CI.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Johnny Billquist]

On 2017-03-09 19:09, Clem Cole wrote:

It looks that way..., but I need some help from Bob or Mark on VH
history,   That was developed at DEC during the period I was off doing
Masscomp/Stellar et al.   During my time earlier time with PDP11 and
Vaxen,  you used DEC DZ's or DEC DH's or Able DHDM's.   As I understand
it, DVH was the mid 1980s' redo of the DH to single board but identical
in SW (i.e. was similar to the Able DHDM) - but I never saw one - so I
don't know what the default addresses, iqr's etc are.  I am assuming you
are defaulting same which means they are what DEC used.


Are we talking DH-11, DHU-11 or DHV-11?
DH-11 was never supported on VAXen. DHU-11 is conceptually the same, but 
it is not software compatible.
DHV-11 was is a qbus device, which can be setup to be compatible with a 
DHU-11.



BSD 4.3 would have been using Able DHDM's so those are the original
addresses of the DEC DH from the PDP-11.

So my question what were the default addresses for the DVH and then from
a simulator stand point, and if different, what happens if you configure
them like the original DH11?


And my first question would be, what kind of device is the DVH?

Johnny



Clem

On Wed, Mar 8, 2017 at 11:49 PM, Cory Smelosky > wrote:

All,

Seems 4.3BSD isn't seeing a DH-11 at all:

4.3 BSD Quasijarus UNIX #0: Sun Mar  7 12:42:05 PST 2004
root@ucbvax:/usr/src/sys/GENERIC
real mem  = 67108864
SYSPTSIZE limits number of buffers to 18
avail mem = 65271808
using 18 buffers containing 147456 bytes of memory
VAX 11/780, serial# 1234(0), hardware ECO level 7(112)
mcr0 (el) at tr1
mcr1 (el) at tr2
uba0 at tr3
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: version 3 model 6
uda0: DMA burst size set to 4
ra0 at uda0 slave 0: ra92, size = 2940951 sectors
Changing root device to ra0a

SHOW CONFIGURATION:
VAX 11/780 simulator configuration

CPU idle=VMS, idle enabled, model=VAX 11/780
64MB, HALT to SIMH
TLB 2 units
  TLB08192W
  TLB18192W
SBI
MCTL0   nexus=1, address=20002000
MCTL1   nexus=2, address=20004000
UBA nexus=3, address=20006000, autoconfiguration enabled
MBA0disabled
MBA1disabled
TODR
12B
TMR
TTI
7b
TTO
7b
CS
256KB, not attached, write enabled
TC  disabled
TDC disabled
DZ  disabled
VH  address=2013E120-2013E15F*, vector=C0-DC*, BR4, lines=64, 4
units
  VH0 attached to 8070, DHU mode, Modem
0 current connections
  VH1 DHU mode
  VH2 DHU mode
  VH3 DHU mode
CR  disabled
LPT disabled
RP  disabled
RL  disabled
HK  disabled
RK  disabled
RQ  address=2013F468-2013F46B, vector=1F8*, BR5, UDA50, 4 units
  RQ0 1505MB, attached to ucbvax-ra92-root.dsk, write enabled
RD54, autosize, SIMH format
RQB disabled
RQC disabled
RQD disabled
RY  address=2013FE78-2013FE7B, vector=B4, BR5, 2 units
  RY0 512KB, not attached, write enabled
double density
  RY1 512KB, not attached, write enabled
double density
TU  disabled
TS  disabled
TQ  TU81 (180MB), address=2013F940-2013F943, vector=1FC*, BR5, 4
units
  TQ0 not attached, write enabled, SIMH format
capacity=188MB
  TQ1 not attached, write enabled, SIMH format
capacity=188MB
  TQ2 not attached, write enabled, SIMH format
capacity=188MB
  TQ3 not attached, write enabled, SIMH format
capacity=188MB
XU  disabled
XUB disabled
DMC disabled

VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
Asynchronous Clock support
FrontPanel API Version 4
Host Platform:
Compiler: GCC 4.2.1 Compatible Apple LLVM 8.0.0
(clang-800.0.42.1)
Simulator Compiled as C arch: x64 (Release Build) on Mar
 8 2017 at 19:55:19
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: No Video Support
PCRE RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by 

Re: [Simh] Now some DZ/terminal questions

[Johnny Billquist]

Clem...

On 2017-03-09 15:58, Clem Cole wrote:

Warren,

We can take this offline.   The quick answer is as far as simh is
concerned leave everything as 8 bits.
I'll show you how to make the rest work properly.  The logins will run 8
bits also, but will run with parity enabled which BSD will handle just
peachy.


As far as I remember, Unixes normally deal with this in the driver, but 
correct me if I'm wrong.



Also, as I mentioned independently, I very much recommend not using DZs,
but using DH's.   Most BSD UNIX boxes ran with Able DHDM's because there
were both higher performant and cheaper than 2 DZ-11 (the cost of single
Able unit got you 16 ports, compared to 8 from DEC, plus they worked
better).  The DZ were originally developed by DEC as a cost reduced
terminal interface to the original DH11 - which was a full system unit
on the Unibus and the DM11 (modem control was an option).  So they took
of a lot of space/power etc.

Unfortunately the DZ were CPU hog's (see one of Bill Joy's notes circa
1979-80 - which I probably have somewhere) and sadly the DZ's did not
support full modem control (which was always a SW nightmare).  I would
later get to know some of the folks that made those choices from DEC's
HW team (they originally screwed up the original MC-500 serial boards
also but that's another story).

Anyway, int he late 1970's Able's Ken O cloned/enhanced the DH and DM
into a single hex board and since the UNIX community was often
university folk, driven by cost (and the DHDM [Able's product] plus did
flow control in HW) they were the gold standard for UUCP, particularly
with Trailblazer et al.


Totally agree. The DZ11 was/is a horrible device. But it must have been 
dirt cheap, as they can still be found everywhere a Unibus exists, more 
or less. I don't know how many I have piled up.


CPU hog only starts to describe it. It interrupts on each character in 
or out, which makes it a really big burden on the CPU. Add that to the 
VAX, which wasn't exactly fast at dealing with interrupts in the first 
place, and you could more or less kill the machine with a few serial 
lines. (It was really bad on a PDP-11 as well.)


The DH11 was a much better device, doing DMA instead, but as you 
mention, it was large. Also, not supported on VAXen.

Able's DH11 clone was a really sweet device. Love it.

DEC came out with the DHU-11 later on, which was similar in many ways.

I never cared much for hardware flow control myself, but for those who 
did, the DZ11 was also a problem, as you say.


All in all, people should just avoid the DZ-11 whenever they have a chance.

Johnny




As I said, we can take this off line, and I'll help you.

Clem

On Thu, Mar 9, 2017 at 7:03 AM, Warren Toomey > wrote:

Hi all, thanks for your help with my earlier questions.

I'd like to set up several vax780 instances and run uucp (over TCP)
between them using one or more of the simulated DZ lines. But I want to
use the remaining DZ lines for logins.

Is there a way to set some DZ lines into 8-bit mode but keep the
other DZ lines in 7-bit mode? Only the uucp lines need to be 8-bit,
the normal login lines can be 7-bit.

Is there a way to set bind some (but not all) DZ lines to localhost
port X,
and some (but not all) DZ lines to any address port Y (or X, doesn't
matter)?
I want to make the uucp DZ TCP ports visible on the Internet, but
set the
normal login ports visible only to localhost.

Many thanks, Warren
___
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




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] CI750 tech docs and VAX firmware

[Paul Koning]

> On Mar 9, 2017, at 1:23 PM, Timothe Litt  wrote:
> 
> I don't have time to dig up the details.  But TOPS-10/20 definitely supported 
> the CI. 

Interesting.  That sounds like a product-specific item rather than part of the 
standard architecture.

paul


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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Paul Koning]

> On Mar 9, 2017, at 3:15 PM, dun...@caltech.edu wrote:
> 
>> So ...If the DHV is supposed to the simh emulation of the combination of a
>> DEC DH11 and DM11 pair (the DM11 was the modem control option for the DH),
>> then this should "just work"
> 
> The SIMH VH device is a simulation of the DEC DHQ device (M3107), a dual
> height Qbus board, normally supporting 8 lines and features DHU/DHV
> "compatibility."  DHV was an earlier quad height incarnation, while the
> DHU was a 16-line Unibus interface.  These are all similar to the historic
> DH/DM combination but not identical.

That sounds right.  DHV is a 8 line Qbus device inspired by DH, close but not 
exactly the same.  DHQ is essentially the same thing made physically smaller.  
DHU is DHV ported to Unibus and 16 lines rather than 8.

Looking at some RSTS code...  DH11 is a different device table entry from VH 
(DHV/DHQ/DHU).  For one thing, it looks like VH has a different floating CSR 
rank.  In addition, the terminal driver has a port driver for DH11, and a 
separate port driver for VH.

So this suggests that if you want DH11 support, you'll want to add DH11 
emulation (preferably with a DM11 option) to SIMH.

paul

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

Re: [Simh] Simh Digest, Vol 158, Issue 14

[William Pechter]

There were 3rd party Unibus to Qbus converters that would handle the signal
Mux/decus issues on the bus lines. 

I never saw any on 11/780 class boxes. 

Crappy UBA was slow.  Most were used to
put Unibus peripherals on Qbus Vaxes. 

Bill

-Original Message-
From: Clem Cole 
To: William Pechter 
Sent: Thu, 09 Mar 2017 15:19
Subject: Re: [Simh] Simh Digest, Vol 158, Issue 14

On Thu, Mar 9, 2017 at 2:54 PM, William Pechter  wrote:

> There was no DH11 driver until the DHV Qbus... And who knows what that was
> compared yo real DH11.


​Let me try to decode that time line and the implications ...


   1. VMS does not officially support the DH11/DM11 combination (ever)...
   (because of your earlier comment about officially not supporting full Unibus
   DH/DM backplane on the UBA - which makes sense.
   2. As Al points out there were DECUS drivers in the wild for them.
   3. At least one of the 3rd party vendors does develop a DH11/DM11
   compatible board which becomes native for UNIX (BTW - we should check the
   Ultrix SPD - I wonder what Ultrix says about -- I bet Ultrix recognizes it,
   but its not in the SPD).
   4. Through the days of the UBA based Vaxen with a full PDP-11 style
   unibus, customers (like me) used either real DH11s with afterwork DH clone
   or in an unsupported bus situation  for UNIX as a minimum. By point 2, we
   can assume the VMS customer are doing the same thing, but we don't have
   anyone that "did it."
   5. Time goes forward, DEC develops the DHV Qbus board.
   6. Was there a Vax based system that had a UBA that spoke QBUS? I
   don't remember such a beast in ZK in the Ultrix lab, and we did not have
   one in pile of gear we at LCC in those days.
   7. Assuming 6 is yes, does that mean VMS supported the DHV on same?
   Again - I do not know.

William do you agree from the HW standard point...  I can verify the UNIX
side of things, but 10 years  development from 1980-'90 I just was not
close to the Vax as I was doing other things.   I got back in early 90's
when LCC took over Ultrix development and Vax support came with the
contract; but I admit I did not as much atten as I had in the 70s,

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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[khandy21yo]

I used DHV11s on Microvax II when they we're real hardware. Worked fine under 
VMS.  I imagine DH11 wasn't different enough for them to not work on unibus.


Sent from my Galaxy Tab® A
 Original message From: Clem Cole  Date: 3/9/17  
12:13 PM  (GMT-07:00) To: Mark Pizzolato  Cc: SIMH 
 Subject: Re: [Simh] Issues with VH simulation and 
4.3BSD-Quasijarus 
Mark... as an FYI if it is of any help..
VH      address=2013E120-2013E15F*, vector=C0-DC*, BR4, lines=64, 4
units
  VH0     attached to 8070, DHU mode, Modem
        0 current connections
  VH1     DHU mode
  VH2     DHU mode
  VH3     DHU mode

device          dhu0    at uba? csr 0160440             vector dhurint

It's been years since, I did this stuff...  
 0160400 is 0xE120  and 0160400 certainly looks right for the Unibus address 
for a DH.   I just can not speak for 0x2013E120 as what is the mapping into the 
Vax address space, but I'll take your word for it that this is correct - that 
is correct.I never saw a real DEC DH on a Vax because of power and space 
issues.That said, we used to mix DEC DH11s and Able DH11's on the PDP-11 all 
the time 
Able DH11's were the most used serial controllers in BSD UNIX land for a long, 
long time, which is why the default BSD configs all probe for them.


So ...If the DHV is supposed to the simh emulation of the combination of a DEC 
DH11 and DM11 pair (the DM11 was the modem control option for the DH), then 
this should "just work" 
That said, I'm not sure if VMS supported real DEC PDP-11 DH11/DM11's in Vaxen.  
I have to believe they would have, but maybe not.  So its possible this has not 
been tested by folks.  I see that a lot of people running simh seem to want to 
use DZ's.
I have not tried the vax simulator a long time - although when I first tried 
it, it was DZ only.   You pointed me at the VH emulation a few years ago, but I 
did not push it very hard.
Thanks,
Clem
On Thu, Mar 9, 2017 at 1:33 PM, Mark Pizzolato  wrote:
You mean DHV, not DVH, right?  DHV is a Qbus variant of some version of the 
DH11 device.  A VAX 780, not having a Qbus, wouldn’t have such a device in its 
configuration. The addresses you see in the SHOW CONFIG output are where the 
simulator will respond to I/O space references.  Those addresses are determined 
dynamically based on the set of devices which are enabled in the simulator 
configuration.  The variable presence of DZ’s and DH’s in the configuration 
would cause the DH to be found at different addresses. If the operating system 
that is being run (BSD 4.3 in this case) is properly configured to look for a 
DH device at the address which the simulated hardware is operating at, then 
things should work.  Device probes when the kernel starts will be visible with 
this in the simulator configuration: sim> set debug -t STDOUT   
 sim> set VH DEBUG=REG If you’re seeing device probes, then the 
kernel’s configuration matches the simulated hardware.  However, if you see the 
probes, but you DON’T see the kernel recognizing the device, then there may be 
a problem with the simulator.  If that is true, please create an issue at 
https://github.com/simh/simh/issues and I’ll dig into the details. -  
Mark From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, March 9, 2017 10:09 AM
To: Cory Smelosky 
Cc: SIMH 
Subject: Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus It looks 
that way..., but I need some help from Bob or Mark on VH history,   That was 
developed at DEC during the period I was off doing Masscomp/Stellar et al.   
During my time earlier time with PDP11 and Vaxen,  you used DEC DZ's or DEC 
DH's or Able DHDM's.   As I understand it, DVH was the mid 1980s' redo of the 
DH to single board but identical in SW (i.e. was similar to the Able DHDM) - 
but I never saw one - so I don't know what the default addresses, iqr's etc 
are.  I am assuming you are defaulting same which means they are what DEC used. 
BSD 4.3 would have been using Able DHDM's so those are the original addresses 
of the DEC DH from the PDP-11. So my question what were the default addresses 
for the DVH and then from a simulator stand point, and if different, what 
happens if you configure them like the original DH11? Clem On Wed, Mar 8, 2017 
at 11:49 PM, Cory Smelosky  wrote:All,

Seems 4.3BSD isn't seeing a DH-11 at all:

4.3 BSD Quasijarus UNIX #0: Sun Mar  7 12:42:05 PST 2004
    root@ucbvax:/usr/src/sys/GENERIC
real mem  = 67108864
SYSPTSIZE limits number of buffers to 18
avail mem = 65271808
using 18 buffers containing 147456 bytes of memory
VAX 11/780, serial# 1234(0), hardware ECO level 7(112)
mcr0 (el) at tr1
mcr1 (el) at tr2
uba0 at tr3
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: 

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[dundas]

> So ...If the DHV is supposed to the simh emulation of the combination of a
> DEC DH11 and DM11 pair (the DM11 was the modem control option for the DH),
> then this should "just work"

The SIMH VH device is a simulation of the DEC DHQ device (M3107), a dual
height Qbus board, normally supporting 8 lines and features DHU/DHV
"compatibility."  DHV was an earlier quad height incarnation, while the
DHU was a 16-line Unibus interface.  These are all similar to the historic
DH/DM combination but not identical.

It's been too long since I looked at the DH/DM combination but if I recall
correctly the actual programming was a bit different from the DHQ, though
the general idea was the same, similar to the Able device.

I have no experience with 4.3BSD-Quasijarus, so I couldn't say with any
authority whether or not it would support the DHQ, but as Mark indicated,
it would need to be set as a DHU for Unibus and 4.3 would likely need to
recognize the difference(s) between DHU and DH/DM.

Also agree with Clem's comment about DZ: a DZ could easily bring a 780 to
its knees with per character interrupts.  The Able board was historically
the first out of the gate, IIRC, to support reasonable serial performance
in the VAX arena.

John

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

Re: [Simh] Simh Digest, Vol 158, Issue 14

[Clem Cole]

On Thu, Mar 9, 2017 at 2:16 PM, William Pechter  wrote:

> Unibus DH/DM backplane s and boards were not supported by DEC on Unibus...


​I assume you mean were not supported on the VAX UBA.  And that would make
sense.​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 158, Issue 14

[Clem Cole]

On Thu, Mar 9, 2017 at 2:16 PM, William Pechter  wrote:

> I did  Field  Service through 8650s and never saw them.  DMF32s - IIRC had
> modem control capability on some lines or is my memory shot.


​DMF32 and DZ had >>partial<< modem control.  It was crock in both cases
and did not work very well, which is why UNIX folks had to use the Able
boards to run Trailblazers or any other high speed modem.

The problem was the flow control was assumed to be in SW (^S/^Q) which
fails if you are running an 8 bit protocol like UUCP.  So you need full HW
modem control with RTS/CTS supported.   DZ's and DMF's supported DTR and CD
but lacked most of the others.


The other issue is that early UARTs had very shallow input buffers.   The
chips that were used in the DZ and DMZ over flowed out high data rates if
there was lots of interrupts.   Again - if you were running something like
a trailblazer modem or the like, where the modem the port connection was at
19.2K or higher, the dropped characters.

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

[Simh] VAX SDL support?

[Sampsa Laine]

Quick question - I saw SDL graphics support mentioned somewhere and wondered 
which emulators have graphics support? Do any of the VAX ones?

Can I run native DECWindows on any of them?

sampsa


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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Clem Cole]

On Thu, Mar 9, 2017 at 2:18 PM, Cory Smelosky  wrote:

> device  dhu0at uba? csr 0160440 vector dhurint
>>
>> It's been years since, I did this stuff...
>>
>>  1.   0160400 is 0xE120  and 0160400 certainly looks right for the
>> Unibus address for a DH.
>>
>
> I'm getting 0xE100 - what am I missing?  Not awake enough today ;)

​I can't type;...   octal 0160440 is hex 0xE120​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Al Kossow]

On 3/9/17 11:18 AM, Cory Smelosky wrote:

>>  3. I never saw a real DEC DH on a Vax because of power and space issues.
>>  4. That said, we used to mix DEC DH11s and Able DH11's on the PDP-11
>> all the time
>>  5. Able DH11's were the most used serial controllers in BSD UNIX land
>> for a long, long time, which is why the default BSD configs all
>> probe for them.
>>

It appears a DH driver existed for VMS at some point
http://www.decuslib.com/decus/vax000/catalog.94a

DH clones were commonly used on BSD. I got some old Infotron ones (ca. 1977) 
and we ran
32 lines on a 750 in the early 80's.

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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Cory Smelosky]

Clem Cole wrote:

Mark... as an FYI if it is of any help..

VH  address=2013E120-2013E15F*, vector=C0-DC*, BR4, lines=64, 4
units
   VH0 attached to 8070, DHU mode, Modem
 0 current connections
   VH1 DHU mode
   VH2 DHU mode
   VH3 DHU mode

device  dhu0at uba? csr 0160440 vector dhurint

It's been years since, I did this stuff...

 1.   0160400 is 0xE120  and 0160400 certainly looks right for the
Unibus address for a DH.


I'm getting 0xE100 - what am I missing?  Not awake enough today ;)


 2.   I just can not speak for 0x2013E120 as what is the mapping into
the Vax address space, but I'll take your word for it that this is
correct - that is correct.
 3. I never saw a real DEC DH on a Vax because of power and space issues.
 4. That said, we used to mix DEC DH11s and Able DH11's on the PDP-11
all the time
 5. Able DH11's were the most used serial controllers in BSD UNIX land
for a long, long time, which is why the default BSD configs all
probe for them.




So ...If the DHV is supposed to the simh emulation of the combination of
a DEC DH11 and DM11 pair (the DM11 was the modem control option for the
DH), then this should "just work"

That said, I'm not sure if VMS supported real DEC PDP-11 DH11/DM11's in
Vaxen.  I have to believe they would have, but maybe not.  So its
possible this has not been tested by folks.  I see that a lot of people
running simh seem to want to use DZ's.

I have not tried the vax simulator a long time - although when I first
tried it, it was DZ only.   You pointed me at the VH emulation a few
years ago, but I did not push it very hard.

Thanks,

Clem


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

Re: [Simh] Simh Digest, Vol 158, Issue 14

[William Pechter]

Unibus DH/DM backplane s and boards were not supported by DEC on Unibus... 

Does Simh support them.

I did  Field  Service through 8650s and never saw them.  DMF32s - IIRC had 
modem control capability on some lines or is my memory shot. 

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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Clem Cole]

Mark... as an FYI if it is of any help..

VH  address=2013E120-2013E15F*, vector=C0-DC*, BR4, lines=64, 4
units
  VH0 attached to 8070, DHU mode, Modem
0 current connections
  VH1 DHU mode
  VH2 DHU mode
  VH3 DHU mode

device  dhu0at uba? csr 0160440 vector dhurint

It's been years since, I did this stuff...


   1.  0160400 is 0xE120  and 0160400 certainly looks right for the Unibus
   address for a DH.
   2.  I just can not speak for 0x2013E120 as what is the mapping into the
   Vax address space, but I'll take your word for it that this is correct -
   that is correct.
   3. I never saw a real DEC DH on a Vax because of power and space issues.
   4. That said, we used to mix DEC DH11s and Able DH11's on the PDP-11 all
   the time
   5. Able DH11's were the most used serial controllers in BSD UNIX land
   for a long, long time, which is why the default BSD configs all probe for
   them.




So ...If the DHV is supposed to the simh emulation of the combination of a
DEC DH11 and DM11 pair (the DM11 was the modem control option for the DH),
then this should "just work"

That said, I'm not sure if VMS supported real DEC PDP-11 DH11/DM11's in
Vaxen.  I have to believe they would have, but maybe not.  So its possible
this has not been tested by folks.  I see that a lot of people running simh
seem to want to use DZ's.

I have not tried the vax simulator a long time - although when I first
tried it, it was DZ only.   You pointed me at the VH emulation a few years
ago, but I did not push it very hard.

Thanks,

Clem

On Thu, Mar 9, 2017 at 1:33 PM, Mark Pizzolato  wrote:

> You mean DHV, not DVH, right?  DHV is a Qbus variant of some version of
> the DH11 device.  A VAX 780, not having a Qbus, wouldn’t have such a device
> in its configuration.
>
>
>
> The addresses you see in the SHOW CONFIG output are where the simulator
> will respond to I/O space references.  Those addresses are determined
> dynamically based on the set of devices which are enabled in the simulator
> configuration.  The variable presence of DZ’s and DH’s in the configuration
> would cause the DH to be found at different addresses.
>
>
>
> If the operating system that is being run (BSD 4.3 in this case) is
> properly configured to look for a DH device at the address which the
> simulated hardware is operating at, then things should work.  Device probes
> when the kernel starts will be visible with this in the simulator
> configuration:
>
>
>
> sim> set debug -t STDOUT
>
> sim> set VH DEBUG=REG
>
>
>
> If you’re seeing device probes, then the kernel’s configuration matches
> the simulated hardware.  However, if you see the probes, but you DON’T see
> the kernel recognizing the device, then there may be a problem with the
> simulator.  If that is true, please create an issue at
> https://github.com/simh/simh/issues and I’ll dig into the details.
>
>
>
> -  Mark
>
>
>
> *From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Clem
> Cole
> *Sent:* Thursday, March 9, 2017 10:09 AM
> *To:* Cory Smelosky 
> *Cc:* SIMH 
> *Subject:* Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus
>
>
>
> It looks that way..., but I need some help from Bob or Mark on VH history,
>   That was developed at DEC during the period I was off doing
> Masscomp/Stellar et al.   During my time earlier time with PDP11 and Vaxen,
>  you used DEC DZ's or DEC DH's or Able DHDM's.   As I understand it, DVH
> was the mid 1980s' redo of the DH to single board but identical in SW (i.e.
> was similar to the Able DHDM) - but I never saw one - so I don't know what
> the default addresses, iqr's etc are.  I am assuming you are defaulting
> same which means they are what DEC used.
>
>
>
> BSD 4.3 would have been using Able DHDM's so those are the original
> addresses of the DEC DH from the PDP-11.
>
>
>
> So my question what were the default addresses for the DVH and then from a
> simulator stand point, and if different, what happens if you configure them
> like the original DH11?
>
>
>
> Clem
>
>
>
> On Wed, Mar 8, 2017 at 11:49 PM, Cory Smelosky  wrote:
>
> All,
>
> Seems 4.3BSD isn't seeing a DH-11 at all:
>
> 4.3 BSD Quasijarus UNIX #0: Sun Mar  7 12:42:05 PST 2004
> root@ucbvax:/usr/src/sys/GENERIC
> real mem  = 67108864
> SYSPTSIZE limits number of buffers to 18
> avail mem = 65271808
> using 18 buffers containing 147456 bytes of memory
> VAX 11/780, serial# 1234(0), hardware ECO level 7(112)
> mcr0 (el) at tr1
> mcr1 (el) at tr2
> uba0 at tr3
> tmscp0 at uba0 csr 174500 vec 774, ipl 15
> tms0 at tmscp0 slave 0
> tms1 at tmscp0 slave 1
> uda0 at uba0 csr 172150 vec 770, ipl 15
> uda0: version 3 model 6
> uda0: DMA burst size set to 4
> ra0 at uda0 slave 0: ra92, size = 2940951 sectors
> Changing root device to ra0a
>
> SHOW CONFIGURATION:
> VAX 11/780 simulator configuration
>
> CPU 

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Clem Cole]

On Thu, Mar 9, 2017 at 1:33 PM, Mark Pizzolato  wrote:

> You mean DHV, not DVH


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

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Cory Smelosky]

On Thu, Mar 9, 2017, at 10:33, Mark Pizzolato wrote:

> You mean DHV, not DVH, right?  DHV is a Qbus variant of some version
> of the DH11 device.  A VAX 780, not having a Qbus, wouldn’t have such
> a device in its configuration.
>  



> The addresses you see in the SHOW CONFIG output are where the
> simulator will respond to I/O space references.  Those addresses are
> determined dynamically based on the set of devices which are enabled
> in the simulator configuration.  The variable presence of DZ’s and
> DH’s in the configuration would cause the DH to be found at different
> addresses.
>  



> If the operating system that is being run (BSD 4.3 in this case) is
> properly configured to look for a DH device at the address which the
> simulated hardware is operating at, then things should work.  Device
> probes when the kernel starts will be visible with this in the
> simulator configuration:
>  



> sim> set debug -t STDOUT



> sim> set VH DEBUG=REG



>  



> If you’re seeing device probes, then the kernel’s configuration
> matches the simulated hardware.  However, if you see the probes, but
> you DON’T see the kernel recognizing the device, then there may be a
> problem with the simulator.  If that is true, please create an issue
> at https://github.com/simh/simh/issues and I’ll dig into the
> details.



https://github.com/simh/simh/issues/409

Seeing probes but not recognising the device.



>  



> -  Mark



>  



> *From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of
> *Clem Cole *Sent:* Thursday, March 9, 2017 10:09 AM *To:* Cory
> Smelosky  *Cc:* SIMH  *Subject:*
> Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus
>  



> It looks that way..., but I need some help from Bob or Mark on VH
> history,   That was developed at DEC during the period I was off
> doing Masscomp/Stellar et al.   During my time earlier time with
> PDP11 and Vaxen,  you used DEC DZ's or DEC DH's or Able DHDM's.   As
> I understand it, DVH was the mid 1980s' redo of the DH to single
> board but identical in SW (i.e. was similar to the Able DHDM) - but I
> never saw one - so I don't know what the default addresses, iqr's etc
> are.  I am assuming you are defaulting same which means they are what
> DEC used.
>  



> BSD 4.3 would have been using Able DHDM's so those are the original
> addresses of the DEC DH from the PDP-11.
>  



> So my question what were the default addresses for the DVH and then
> from a simulator stand point, and if different, what happens if you
> configure them like the original DH11?
>  



> Clem



>  



> On Wed, Mar 8, 2017 at 11:49 PM, Cory Smelosky  wrote:
>> All,
>>
>> Seems 4.3BSD isn't seeing a DH-11 at all:
>>
>> 4.3 BSD Quasijarus UNIX #0: Sun Mar  7 12:42:05 PST 2004
>>   root@ucbvax:/usr/src/sys/GENERIC real mem  = 67108864 SYSPTSIZE
>>   limits number of buffers to 18 avail mem = 65271808 using 18
>>   buffers containing 147456 bytes of memory VAX 11/780, serial#
>>   1234(0), hardware ECO level 7(112) mcr0 (el) at tr1 mcr1 (el) at
>>   tr2 uba0 at tr3 tmscp0 at uba0 csr 174500 vec 774, ipl 15 tms0 at
>>   tmscp0 slave 0 tms1 at tmscp0 slave 1 uda0 at uba0 csr 172150 vec
>>   770, ipl 15 uda0: version 3 model 6 uda0: DMA burst size set to 4
>>   ra0 at uda0 slave 0: ra92, size = 2940951 sectors Changing root
>>   device to ra0a
>>
>> SHOW CONFIGURATION: VAX 11/780 simulator configuration
>>
>> CPU idle=VMS, idle enabled, model=VAX 11/78064MB, HALT to
>> SIMH TLB 2 units  TLB08192W  TLB18192W SBI MCTL0
>> nexus=1, address=20002000 MCTL1   nexus=2, address=20004000 UBA
>> nexus=3, address=20006000, autoconfiguration enabled MBA0disabled
>> MBA1disabled TODR12B TMR TTI7b TTO7b CS
>> 256KB, not attached, write enabled TC  disabled TDC disabled
>> DZ  disabled VH  address=2013E120-2013E15F*, vector=C0-DC*,
>> BR4, lines=64, 4 units  VH0 attached to 8070, DHU mode, Modem
>> current connections  VH1 DHU mode  VH2 DHU mode  VH3 DHU
>> mode CR  disabled LPT disabled RP  disabled RL
>> disabled HK  disabled RK  disabled RQ  address=2013F468-
>> 2013F46B, vector=1F8*, BR5, UDA50, 4 units  RQ0 1505MB, attached
>> to ucbvax-ra92-root.dsk, write enabledRD54, autosize, SIMH
>> format RQB disabled RQC disabled RQD disabled RY  
>> address=2013FE78-
>> 2013FE7B, vector=B4, BR5, 2 units  RY0 512KB, not attached, write
>> enableddouble density  RY1 512KB, not attached, write
>> enableddouble density TU  disabled TS  disabled TQ
>> TU81 (180MB), address=2013F940-2013F943, vector=1FC*, BR5, 4 units
>> TQ0 not attached, write enabled, SIMH format
>> capacity=188MB  TQ1 not attached, write enabled, SIMH format
>> capacity=188MB  TQ2 not attached, write enabled, SIMH format
>> capacity=188MB  TQ3 

Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

[Mark Pizzolato]

You mean DHV, not DVH, right?  DHV is a Qbus variant of some version of the 
DH11 device.  A VAX 780, not having a Qbus, wouldn’t have such a device in its 
configuration.

The addresses you see in the SHOW CONFIG output are where the simulator will 
respond to I/O space references.  Those addresses are determined dynamically 
based on the set of devices which are enabled in the simulator configuration.  
The variable presence of DZ’s and DH’s in the configuration would cause the DH 
to be found at different addresses.

If the operating system that is being run (BSD 4.3 in this case) is properly 
configured to look for a DH device at the address which the simulated hardware 
is operating at, then things should work.  Device probes when the kernel starts 
will be visible with this in the simulator configuration:

sim> set debug -t STDOUT
sim> set VH DEBUG=REG

If you’re seeing device probes, then the kernel’s configuration matches the 
simulated hardware.  However, if you see the probes, but you DON’T see the 
kernel recognizing the device, then there may be a problem with the simulator.  
If that is true, please create an issue at https://github.com/simh/simh/issues 
and I’ll dig into the details.


-  Mark

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Clem Cole
Sent: Thursday, March 9, 2017 10:09 AM
To: Cory Smelosky 
Cc: SIMH 
Subject: Re: [Simh] Issues with VH simulation and 4.3BSD-Quasijarus

It looks that way..., but I need some help from Bob or Mark on VH history,   
That was developed at DEC during the period I was off doing Masscomp/Stellar et 
al.   During my time earlier time with PDP11 and Vaxen,  you used DEC DZ's or 
DEC DH's or Able DHDM's.   As I understand it, DVH was the mid 1980s' redo of 
the DH to single board but identical in SW (i.e. was similar to the Able DHDM) 
- but I never saw one - so I don't know what the default addresses, iqr's etc 
are.  I am assuming you are defaulting same which means they are what DEC used.

BSD 4.3 would have been using Able DHDM's so those are the original addresses 
of the DEC DH from the PDP-11.

So my question what were the default addresses for the DVH and then from a 
simulator stand point, and if different, what happens if you configure them 
like the original DH11?

Clem

On Wed, Mar 8, 2017 at 11:49 PM, Cory Smelosky 
> wrote:
All,

Seems 4.3BSD isn't seeing a DH-11 at all:

4.3 BSD Quasijarus UNIX #0: Sun Mar  7 12:42:05 PST 2004
root@ucbvax:/usr/src/sys/GENERIC
real mem  = 67108864
SYSPTSIZE limits number of buffers to 18
avail mem = 65271808
using 18 buffers containing 147456 bytes of memory
VAX 11/780, serial# 1234(0), hardware ECO level 7(112)
mcr0 (el) at tr1
mcr1 (el) at tr2
uba0 at tr3
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: version 3 model 6
uda0: DMA burst size set to 4
ra0 at uda0 slave 0: ra92, size = 2940951 sectors
Changing root device to ra0a

SHOW CONFIGURATION:
VAX 11/780 simulator configuration

CPU idle=VMS, idle enabled, model=VAX 11/780
64MB, HALT to SIMH
TLB 2 units
  TLB08192W
  TLB18192W
SBI
MCTL0   nexus=1, address=20002000
MCTL1   nexus=2, address=20004000
UBA nexus=3, address=20006000, autoconfiguration enabled
MBA0disabled
MBA1disabled
TODR
12B
TMR
TTI
7b
TTO
7b
CS
256KB, not attached, write enabled
TC  disabled
TDC disabled
DZ  disabled
VH  address=2013E120-2013E15F*, vector=C0-DC*, BR4, lines=64, 4
units
  VH0 attached to 8070, DHU mode, Modem
0 current connections
  VH1 DHU mode
  VH2 DHU mode
  VH3 DHU mode
CR  disabled
LPT disabled
RP  disabled
RL  disabled
HK  disabled
RK  disabled
RQ  address=2013F468-2013F46B, vector=1F8*, BR5, UDA50, 4 units
  RQ0 1505MB, attached to ucbvax-ra92-root.dsk, write enabled
RD54, autosize, SIMH format
RQB disabled
RQC disabled
RQD disabled
RY  address=2013FE78-2013FE7B, vector=B4, BR5, 2 units
  RY0 512KB, not attached, write enabled
double density
  RY1 512KB, not attached, write enabled
double density
TU  disabled
TS  disabled
TQ  TU81 (180MB), address=2013F940-2013F943, vector=1FC*, BR5, 4
units
  TQ0 not attached, write enabled, SIMH format
capacity=188MB
  TQ1 not attached, write enabled, SIMH format
capacity=188MB
  TQ2 not attached, write enabled, SIMH format
capacity=188MB
  TQ3 not attached, write enabled, SIMH format
capacity=188MB
XU  disabled
XUB disabled
DMC disabled

VAX 11/780 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP

Re: [Simh] HSC vs UDA/QDA

[Mark Pizzolato]

The simh VAX simulators will readily participate in LAVC clustering with 
other simh simulators and/or real VAX systems as long as they're all present 
on the same LAN.

How to configure and/or manage cluster systems is described in various 
DEC documents with nothing special relevant to the having one or more 
simulated systems participating in the cluster.

- Mark

On Thursday, March 9, 2017 at 10:21 AM, Paul Koning wrote:
> If you configure ethernet, I'd expect that would "just work".  Not being a VMS
> user I haven't tried this.
> 
>   paul
> 
> > On Mar 9, 2017, at 12:05 PM, Tim Stark  wrote:
> >
> > Hmm. How to use LAVC for clustering?
> >
> > Thanks,
> > Tim
> 
> ___
> 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

Re: [Simh] CI750 tech docs and VAX firmware

[Paul Koning]

> On Mar 9, 2017, at 12:27 PM, Timothe Litt  wrote:
> 
> ..
> With respect to an earlier question about CI emulation:  The best approach 
> may be to emulate it as multicast ethernet.  Setup a couple of groups for 
> each star coupler.  Each coupler supports up to 32 nodes.  For VMS, half o 
> them hosts, half storage.  CI is a 50Mb/s (might be 70, but I remember 50 
> from the initial doc) CSMA/CD bus.

70 Mb/s is the number I always saw.

>  The cabling is redundant (A & B cables), so assign one MC group to each per 
> star.  (Yes, there are DECnet drivers for on multiple OSs.  I think it was 
> considered a multipoint medium with addresses related to (CI) node numbers 
> rather than an ethernet (broadcast) - but it's been a while.)

I don't think DECnet ever supported CI.  It certainly doesn't show up in the 
DECnet architecture specs anywhere.

paul

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

Re: [Simh] CI750 tech docs and VAX firmware

[Timothe Litt]

The CI interface is the KLIPA.  Its a KL10-only device that sits in an
RH20 channel slot.  It uses a port architecture similar to the CI780,
with queues and 36-bit pointers in physical memory.  It's supported in 7.04.

With respect to an earlier question about CI emulation:  The best
approach may be to emulate it as multicast ethernet.  Setup a couple of
groups for each star coupler.  Each coupler supports up to 32 nodes. 
For VMS, half o them hosts, half storage.  CI is a 50Mb/s (might be 70,
but I remember 50 from the initial doc) CSMA/CD bus.  The cabling is
redundant (A & B cables), so assign one MC group to each per star. 
(Yes, there are DECnet drivers for on multiple OSs.  I think it was
considered a multipoint medium with addresses related to (CI) node
numbers rather than an ethernet (broadcast) - but it's been a while.)


Have fun.

On 09-Mar-17 11:58, Tim Stark wrote:
> Folks,
>
> Hmm.   I checked TOPS-10 7.04 monitor source codes and found two files about 
> SCS/SCA packet info but did not find any files about CI interface. 
> I think TOPS-10 can communicate through DECnet.
>
> I think that transport layers are SCS/SCA layers. 
>
> There is commercial emulator (Charon-VAX) emulates CI hardware and HSJ50 
> controllers.  They are much faster than actual CI hardware.
>
> So that we can implement them on SIMH and other emulators possibly.
>
> Tim
>
> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Rich Alderson
> Sent: Tuesday, March 7, 2017 2:37 PM
> To: simh@trailing-edge.com
> Subject: Re: [Simh] CI750 tech docs and VAX firmware
>
>> Unless I remember totally wrong, only the HSC50 could do 576 byte sectors.
>> It was dropped in a pretty early version of CRONIC, before support for 
>> any other HSC controller existed.
> Correct.  Only the HSC50 ever supported 576-byte sectors, and only on RA81 
> and smaller drives.  (We really wanted RA82s on our 4-system CI cluster at 
> Stanford LOTS, but were informed that it would never ever happen.)
>
> Rich 
> ___
> 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



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

Re: [Simh] HSC vs UDA/QDA

[Mark Pizzolato]

On Wednesday, March 8, 2017 at 11:50 PM, Johnny Billquist wrote:
> On 2017-03-09 02:26, Paul Koning wrote:
> >
> >> On Mar 8, 2017, at 7:44 PM, Johnny Billquist  wrote:
> >>
> >> On 2017-03-08 22:15, Bob Supnik wrote:
> >>> 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.
> >>
> >> Oh. I didnät mean to imply that the HSC was just the same as an UDA. But
> >> the MSCP protocol as such is the same between them. Shadowing, local disk
> >> copying, caching and so on, are just things a controller can do without the
> >> host are even aware of it happening.
> >> But since we're talking emulation, the actual disks now might be doing
> >> even more of that than an HSC ever could. It's not really something that
> >> makes much sense to emulate.
> >
> > I think the significant different for emulation, as opposed for the real
> > hardware, is that CI is a multi-access network (like Ethernet).  All the 
> > hosts can
> > see all the disks, and in addition the hosts have peer to peer 
> > communication.
> > VAXclusters use both of these things.  You can of course do them via LAVC
> > (same services but over Ethernet).  With CI emulation you get a second way.
> > That enables running clusters with VMS versions predating LAVC, if that is
> > interesting to anyone.
> 
> Yes.
> 
> However, to get that working you will either need to run several emulated
> machines under the same simh instance, or have the CI run outside of the
> simh framework, so that several simh instances can communicate with it.
> While possible, this could turn complicated.
> If you only do CI within CI, with the limit to one machine, then all that is 
> lost,
> and you end up with the same as a local MSCP and TMSCP controller, with
> just a different transport layer you need to implement.

When Matt Burke initially was working on this, I believe that we talked briefly
about extending sim_ether to support packet delivery across IP multicast.  
With that model, all of the systems connected to a particular star coupler 
would use the same multi-cast group.  I think that DEC may have done 
something very similar to this when they implemented LAVC.  Several 
independent Local Area VAX Clusters can certainly coexist on the same 
LAN without interference.

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

Re: [Simh] Now some DZ/terminal questions

[Mark Pizzolato]

On Thursday, March 9, 2017 at 4:04 AM, Warren Toomey wrote:
> Is there a way to set bind some (but not all) DZ lines to localhost port X,
> and some (but not all) DZ lines to any address port Y (or X, doesn't matter)?
> I want to make the uucp DZ TCP ports visible on the Internet, but set the
> normal login ports visible only to localhost.

There is no way to have different collections of lines bound to different 
TCP ports.  There is a way to have individual lines have their own listen port
while all other lines share a single listen port.

sim> ATTACH DZ X,Line=3,Y,line=4,Z

will have line 3 listen on TCP port Y and line listen on TCP port Z and all 
other lines will get connections on TCP port X.

The details of what is configured is visible with the SHOW MUX command.

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

Re: [Simh] Now some DZ/terminal questions

[Clem Cole]

Warren,

We can take this offline.   The quick answer is as far as simh is concerned
leave everything as 8 bits.
I'll show you how to make the rest work properly.  The logins will run 8
bits also, but will run with parity enabled which BSD will handle just
peachy.

Also, as I mentioned independently, I very much recommend not using DZs,
but using DH's.   Most BSD UNIX boxes ran with Able DHDM's because there
were both higher performant and cheaper than 2 DZ-11 (the cost of single
Able unit got you 16 ports, compared to 8 from DEC, plus they worked
better).  The DZ were originally developed by DEC as a cost reduced
terminal interface to the original DH11 - which was a full system unit on
the Unibus and the DM11 (modem control was an option).  So they took of a
lot of space/power etc.

Unfortunately the DZ were CPU hog's (see one of Bill Joy's notes circa
1979-80 - which I probably have somewhere) and sadly the DZ's did not
support full modem control (which was always a SW nightmare).  I would
later get to know some of the folks that made those choices from DEC's HW
team (they originally screwed up the original MC-500 serial boards also but
that's another story).

Anyway, int he late 1970's Able's Ken O cloned/enhanced the DH and DM into
a single hex board and since the UNIX community was often university folk,
driven by cost (and the DHDM [Able's product] plus did flow control in HW)
they were the gold standard for UUCP, particularly with Trailblazer et al.


As I said, we can take this off line, and I'll help you.

Clem

On Thu, Mar 9, 2017 at 7:03 AM, Warren Toomey  wrote:

> Hi all, thanks for your help with my earlier questions.
>
> I'd like to set up several vax780 instances and run uucp (over TCP)
> between them using one or more of the simulated DZ lines. But I want to
> use the remaining DZ lines for logins.
>
> Is there a way to set some DZ lines into 8-bit mode but keep the
> other DZ lines in 7-bit mode? Only the uucp lines need to be 8-bit,
> the normal login lines can be 7-bit.
>
> Is there a way to set bind some (but not all) DZ lines to localhost port X,
> and some (but not all) DZ lines to any address port Y (or X, doesn't
> matter)?
> I want to make the uucp DZ TCP ports visible on the Internet, but set the
> normal login ports visible only to localhost.
>
> Many thanks, Warren
> ___
> 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