[Simh] Issues with VH simulation and 4.3BSD-Quasijarus
Clem Cole
clemc at ccc.com
Thu Mar 9 14:13:38 EST 2017
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...
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 <Mark at infocomm.com> 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-bounces at trailing-edge.com] *On Behalf Of *Clem
> Cole
> *Sent:* Thursday, March 9, 2017 10:09 AM
> *To:* Cory Smelosky <b4 at gewt.net>
> *Cc:* SIMH <simh at trailing-edge.com>
> *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 <b4 at gewt.net> 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 at 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
> TLB0 8192W
> TLB1 8192W
> SBI
> MCTL0 nexus=1, address=20002000
> MCTL1 nexus=2, address=20004000
> UBA nexus=3, address=20006000, autoconfiguration enabled
> MBA0 disabled
> MBA1 disabled
> 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 msleep(1): 1ms
> OS: Darwin maelona.local 16.4.0 Darwin Kernel Version
> 16.4.0: Thu Dec 22 22:53:21 PST 2016;
> root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64
> git commit id: b41d10f1
>
> Excerpt from kernel config:
> device dhu0 at uba? csr 0160440 vector dhurint
> dhuxint
>
> Is it a config error?
>
> --
> Cory Smelosky
> b4 at gewt.net
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170309/38ab56e5/attachment-0001.html>
More information about the Simh
mailing list