From quentin at quentin.org.uk  Tue Jun 10 06:28:25 2014
From: quentin at quentin.org.uk (Quentin North)
Date: Tue, 10 Jun 2014 11:28:25 +0100
Subject: [Simh] Principal vintage software developer
In-Reply-To: <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
Message-ID: <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>

I saw this job advertised in Seattle which may be of interest to members of the list

http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job

Brush off your PDP and CDC skills. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140610/107af00c/attachment.html>

From aek at bitsavers.org  Tue Jun 10 09:13:58 2014
From: aek at bitsavers.org (Al Kossow)
Date: Tue, 10 Jun 2014 06:13:58 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
Message-ID: <53970496.1050909@bitsavers.org>

On 6/10/14 3:28 AM, Quentin North wrote:
> I saw this job advertised in Seattle which may be of interest to members of the list
>
> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>
> Brush off your PDP and CDC skills.
>

I would suggest emailing Ian King before considering a job there.




From phiber at phiber.com  Tue Jun 10 18:33:05 2014
From: phiber at phiber.com (Mark Abene)
Date: Tue, 10 Jun 2014 15:33:05 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <53970496.1050909@bitsavers.org>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
Message-ID: <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>

...and getting fitted for a kilt.



On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:

> On 6/10/14 3:28 AM, Quentin North wrote:
>
>> I saw this job advertised in Seattle which may be of interest to members
>> of the list
>>
>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>>
>> Brush off your PDP and CDC skills.
>>
>>
> I would suggest emailing Ian King before considering a job there.
>
>
>
> _______________________________________________
> 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/20140610/e3346c6c/attachment.html>

From b4 at gewt.net  Mon Jun 16 02:11:50 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 02:11:50 -0400 (EDT)
Subject: [Simh] VAX-11/780 simulator: rx device
Message-ID: <alpine.OSX.2.00.1406160209260.15321@melanie.local>

Hello all,

What happened to the RX device in the VAX simulators?  I see the source 
file is still there...but it's been removed from the makefile.

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

From b4 at gewt.net  Mon Jun 16 02:44:19 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 02:44:19 -0400 (EDT)
Subject: [Simh] VAX-11/780 simulator: rx device
In-Reply-To: <alpine.OSX.2.00.1406160209260.15321@melanie.local>
References: <alpine.OSX.2.00.1406160209260.15321@melanie.local>
Message-ID: <alpine.OSX.2.00.1406160243590.15321@melanie.local>

On Mon, 16 Jun 2014, Cory Smelosky wrote:

> Hello all,
>
> What happened to the RX device in the VAX simulators?  I see the source file 
> is still there...but it's been removed from the makefile.
>

Ahh.  It got renamed to CS from RX.  Makes sense.

Please remove the volume "eeeeeeeeeeee" from the console device

Now I can proceed. ;)

>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

From simh at alderson.users.panix.com  Mon Jun 16 20:06:02 2014
From: simh at alderson.users.panix.com (Rich Alderson)
Date: Mon, 16 Jun 2014 20:06:02 -0400 (EDT)
Subject: [Simh] Principal vintage software developer
In-Reply-To: <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 (message from Mark Abene on Tue, 10 Jun 2014 15:33:05 -0700)
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
Message-ID: <20140617000602.E0614242E4@panix5.panix.com>

> Date: Tue, 10 Jun 2014 15:33:05 -0700
> From: Mark Abene <phiber at phiber.com>

> On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:

>> On 6/10/14 3:28 AM, Quentin North wrote:

>>> I saw this job advertised in Seattle which may be of interest to members
>>> of the list

>>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job

>>> Brush off your PDP and CDC skills.

>> I would suggest emailing Ian King before considering a job there.

> ...and getting fitted for a kilt.

Ian was the only person at LCM who wore a kilt; it's not a job requirement.

I won't try to speak for Ian, but I will point out that he posted a defense of
the job listing (as did Mike Ross) at The Register when commentors on this same
listing took cheap shots at it based on no information.

http://www.theregister.co.uk/2014/06/10/vintage_coder_remember_control_data_the_lcm_wants_you/

Feel free to ask me about it, too.  I won't lie about it.  I am, after all, in
the same job as Ian was and I've been here 5 years longer.  (I interviewed Ian
for the job.)

                                                                Rich

From phiber at phiber.com  Tue Jun 17 02:18:33 2014
From: phiber at phiber.com (Mark Abene)
Date: Mon, 16 Jun 2014 23:18:33 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <20140617000602.E0614242E4@panix5.panix.com>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
Message-ID: <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>

The kilt reference is what we call a "joke".
If I wore a giant sombrero to work, it would no doubt be all over the
Internet.
There is still humor left in the world, I'm sure of it.



On Mon, Jun 16, 2014 at 5:06 PM, Rich Alderson <
simh at alderson.users.panix.com> wrote:

> > Date: Tue, 10 Jun 2014 15:33:05 -0700
> > From: Mark Abene <phiber at phiber.com>
>
> > On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:
>
> >> On 6/10/14 3:28 AM, Quentin North wrote:
>
> >>> I saw this job advertised in Seattle which may be of interest to
> members
> >>> of the list
>
> >>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>
> >>> Brush off your PDP and CDC skills.
>
> >> I would suggest emailing Ian King before considering a job there.
>
> > ...and getting fitted for a kilt.
>
> Ian was the only person at LCM who wore a kilt; it's not a job requirement.
>
> I won't try to speak for Ian, but I will point out that he posted a
> defense of
> the job listing (as did Mike Ross) at The Register when commentors on this
> same
> listing took cheap shots at it based on no information.
>
>
> http://www.theregister.co.uk/2014/06/10/vintage_coder_remember_control_data_the_lcm_wants_you/
>
> Feel free to ask me about it, too.  I won't lie about it.  I am, after
> all, in
> the same job as Ian was and I've been here 5 years longer.  (I interviewed
> Ian
> for the job.)
>
>                                                                 Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140616/d45dade8/attachment-0001.html>

From simh at alderson.users.panix.com  Tue Jun 17 15:14:28 2014
From: simh at alderson.users.panix.com (Rich Alderson)
Date: Tue, 17 Jun 2014 15:14:28 -0400 (EDT)
Subject: [Simh] Principal vintage software developer
In-Reply-To: <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 (message from Mark Abene on Mon, 16 Jun 2014 23:18:33 -0700)
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
Message-ID: <20140617191428.D92C9242E3@panix5.panix.com>

> Date: Mon, 16 Jun 2014 23:18:33 -0700
> From: Mark Abene <phiber at phiber.com>

> The kilt reference is what we call a "joke".
> If I wore a giant sombrero to work, it would no doubt be all over the
> Internet.

I knew it was a joke, or I'd not have addressed it.

But my friend Al was not joking.  Things were briefly bad in the umbrella
organization that pays the engineering staff at the museum, and Ian and I
got caught in that.  It's no longer a problem, but we lost Ian because of
it.

> There is still humor left in the world, I'm sure of it.

Oh, there is.  Trouble is, some of the wounds are still salty.

                                                                Rich

From aek at bitsavers.org  Tue Jun 17 16:26:34 2014
From: aek at bitsavers.org (Al Kossow)
Date: Tue, 17 Jun 2014 13:26:34 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <20140617191428.D92C9242E3@panix5.panix.com>
References: <2070758.hMozsa9Jsr@lobster>	<69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>	<DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>	<53970496.1050909@bitsavers.org>	<CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>	<20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 <20140617191428.D92C9242E3@panix5.panix.com>
Message-ID: <53A0A47A.30702@bitsavers.org>

On 6/17/14 12:14 PM, Rich Alderson wrote:
> Things were briefly bad in the umbrella
> organization that pays the engineering staff at the museum, and Ian and I
> got caught in that.  It's no longer a problem, but we lost Ian because of
> it.
>

It's good to hear things are better now.




From phiber at phiber.com  Wed Jun 18 22:14:05 2014
From: phiber at phiber.com (Mark Abene)
Date: Wed, 18 Jun 2014 19:14:05 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <53A0A47A.30702@bitsavers.org>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 <20140617191428.D92C9242E3@panix5.panix.com>
 <53A0A47A.30702@bitsavers.org>
Message-ID: <CAPCE1iZQ4qjOXjLHJnDiSb+j8gfF7GaHims4W8TYcWZosU+V3Q@mail.gmail.com>

I've been an XKLeTen user for a bunch of years, so it would definitely be
uncool if this and other museum awesomeness were negatively affected by a
billion-dollar parent company not allocating enough budget to the right
people.




On Tue, Jun 17, 2014 at 1:26 PM, Al Kossow <aek at bitsavers.org> wrote:

> On 6/17/14 12:14 PM, Rich Alderson wrote:
>
>> Things were briefly bad in the umbrella
>> organization that pays the engineering staff at the museum, and Ian and I
>> got caught in that.  It's no longer a problem, but we lost Ian because of
>> it.
>>
>>
> It's good to hear things are better now.
>
>
>
>
> _______________________________________________
> 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/20140618/9afacfff/attachment.html>

From hbent at oberlin.edu  Thu Jun 26 21:09:10 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Thu, 26 Jun 2014 21:09:10 -0400
Subject: [Simh] Ultrix 1.0
Message-ID: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
on the MicroVAX 1 simulator.  It appears that the distribution there was
only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
cleanly, albeit with quite a bit of disk swapping - the installation disk
set is 13 floppies.

The QVSS is supported and will display some output on boot.  I haven't yet
looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references
to a qe device - but I can't figure out how to get it recognized.
Unfortunately there are no kernel config files in the distribution, so I
have no idea if the stock kernel is expecting the controller at a
non-standard address.  Any help with this would be greatly appreciated,

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/6d763bbe/attachment.html>

From b4 at gewt.net  Thu Jun 26 21:19:03 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 26 Jun 2014 21:19:03 -0400 (Eastern Daylight Time)
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <alpine.WNT.2.01.1406262118310.3040@melanie.gimme-sympathy.org>

On Thu, 26 Jun 2014, Henry Bent wrote:

> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>

I'd take a look...but the MVI simulator will build but not run for me. :( 
I need to debug further and see if it was OS-specific.

> -Henry
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

From hbent at oberlin.edu  Thu Jun 26 21:28:51 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Thu, 26 Jun 2014 21:28:51 -0400
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>
Message-ID: <CAKJ3OjnK2fyRK8EQ9MaUnu8MvCpuYwd1+9POxXXGqO9UfYZ71A@mail.gmail.com>

Thanks for the info, I've never worked with physical VAX hardware this
old.  The kernel is definitely accessing the DEQNA, here's what the debug
output shows during boot:

DBG(21694666)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0)
DBG(21694666)> XQ REG:    data=0xFF08
DBG(21694681)> XQ REG: xq_wr(data=0x00000002, PA=0x2000192E[CSR], access=2)
DBG(21694681)> XQ REG: xq_wr_csr(data=0x00000002)
DBG(21694684)> XQ REG: xq_wr(data=0x000001F8, PA=0x2000192C[VAR], access=2)
DBG(21694684)> XQ REG: xq_wr_var(data= 0x000001F8)
DBG(21694766)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0)
DBG(21694766)> XQ REG:    data=0xFF08
DBG(21694769)> XQ REG: xq_rd(PA=0x20001922 [MAC1], access=0)
DBG(21694769)> XQ REG:    data=0xFF00
DBG(21694772)> XQ REG: xq_rd(PA=0x20001924 [MAC2], access=0)
DBG(21694772)> XQ REG:    data=0xFF2B
DBG(21694775)> XQ REG: xq_rd(PA=0x20001926 [MAC3], access=0)
DBG(21694775)> XQ REG:    data=0xFFAA
DBG(21694778)> XQ REG: xq_rd(PA=0x20001928 [MAC4], access=0)
DBG(21694778)> XQ REG:    data=0xFFBB
DBG(21694781)> XQ REG: xq_rd(PA=0x2000192A [MAC5], access=0)
DBG(21694781)> XQ REG:    data=0xFFCC
DBG(21695029)> XQ REG: xq_wr(data=0x000080C0, PA=0x2000192E[CSR], access=2)
DBG(21695029)> XQ REG: xq_wr_csr(data=0x000080C0)
DBG(21695031)> XQ REG: xq_wr(data=0x00001E78, PA=0x20001924[RBDL-Lo],
access=2)
DBG(21695034)> XQ REG: xq_wr(data=0x00000004, PA=0x20001926[RBDL-Hi],
access=2)
DBG(21695037)> XQ REG: xq_wr(data=0x00002158, PA=0x20001928[XBDL-Lo],
access=2)
DBG(21695041)> XQ REG: xq_wr(data=0x00000004, PA=0x2000192A[XBDL-Hi],
access=2)

I uploaded the RD52 image and the output of "sh c" here, anyone is welcome
to use it for whatever:
http://cs.oberlin.edu/~hbent/vaxultrix/ultrix1.tar.bz2

-Henry


On 26 June 2014 21:16, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:

> Hi Henry,
>
>
>
> There are only two possible addresses for a DEQNA device, and I?m very
> sure that the expected address is the primary address which should be the
> default.
>
>
>
> You can verify that the kernel is attempting to touch the Qbus register
> space for the DEQNA device with the following simh commands added to your
> simh configuration:
>
>
>
>     sim> set xq debug=REG
>
>     sim> set debug stdout
>
>
>
> Boot the simulator and the debug output should show any register
> references which may be occurring.
>
>
>
> If you truly believe that the DEQNA device isn?t working properly I can
> dig into the details if you can provide an RD51 or RD52 disk image and the
> configuration file you?re working with.
>
>
>
> Good Luck,
>
>
>
> -          Mark
>
>
>
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Henry Bent
> *Sent:* Thursday, June 26, 2014 6:09 PM
> *To:* simh at trailing-edge.com
> *Subject:* [Simh] Ultrix 1.0
>
>
>
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>
> -Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/0e0f3c9d/attachment-0001.html>

From Mark at infocomm.com  Thu Jun 26 21:16:38 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 26 Jun 2014 18:16:38 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>

Hi Henry,

There are only two possible addresses for a DEQNA device, and I?m very sure that the expected address is the primary address which should be the default.

You can verify that the kernel is attempting to touch the Qbus register space for the DEQNA device with the following simh commands added to your simh configuration:

    sim> set xq debug=REG
    sim> set debug stdout

Boot the simulator and the debug output should show any register references which may be occurring.

If you truly believe that the DEQNA device isn?t working properly I can dig into the details if you can provide an RD51 or RD52 disk image and the configuration file you?re working with.

Good Luck,


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 6:09 PM
To: simh at trailing-edge.com
Subject: [Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/14ad4cdf/attachment.html>

From b4 at gewt.net  Thu Jun 26 21:33:46 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 26 Jun 2014 21:33:46 -0400 (Eastern Daylight Time)
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC20@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <alpine.WNT.2.01.1406262118310.3040@melanie.gimme-sympathy.org>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC20@REDROOF2.alohasunset.com>
Message-ID: <alpine.WNT.2.01.1406262132400.3040@melanie.gimme-sympathy.org>

On Thu, 26 Jun 2014, Mark Pizzolato - Info Comm wrote:

> Hi Cory,
>
> On Thursday, June 26, 2014 at 6:19 PM, Cory Smelosky wrote:
>> I'd take a look...but the MVI simulator will build but not run for me. :( I need
>> to debug further and see if it was OS-specific.
>
> What platform are you doing this on?
>

OS X Mavericks/Yosemite.  Unfortunately as a result of (unrelated) anger 
the disk was wiped.  I can get access to a friend's box, though.

And...apparently my email to you is "unsolicited" despite me being listed 
on 0 blacklists I know of...

> Thanks.
>
> - Mark
>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

From jsteve at superglobalmegacorp.com  Thu Jun 26 22:35:15 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 27 Jun 2014 10:35:15 +0800
Subject: [Simh] Ultrix 1.0
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>

I wonder if it's related to the BSD driver for the network card.... Years
ago I was playing with 4.2 and 4.3BSD and I never could get the network card
to work, so I started to play with the driver, and I found this:

 

In the  if_de.c driver there is some error checking, that always seems to
come back with errors.

 

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

/*

 * Ethernet interface receiver interface.

 * If input error just drop packet.

 * Otherwise purge input buffered data path and examine

 * packet to determine type.  If can't determine length

 * from type, then have to drop packet.  Othewise decapsulate

 * packet based on type and pass to type specific higher-level

 * input routine.

 */

derecv(unit)

        int unit;

{

        register struct de_softc *ds = &de_softc[unit];

        register struct de_ring *rp;

        int len;

 

        rp = &ds->ds_rrent[ds->ds_rindex];

        while ((rp->r_flags & RFLG_OWN) == 0) {

                ds->ds_if.if_ipackets++;

                if (ds->ds_deuba.iff_flags & UBA_NEEDBDP)

                        UBAPURGE(ds->ds_deuba.iff_uba,

                        ds->ds_ifr[ds->ds_rindex].ifrw_bdp);

                len = (rp->r_lenerr&RERR_MLEN) - sizeof (struct
ether_header)

                        - 4;    /* don't forget checksum! */

                /* check for errors */

               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

                    (rp->r_flags&(RFLG_STP|RFLG_ENP)) != (RFLG_STP|RFLG_ENP)
||

                    (rp->r_lenerr & (RERR_BUFL|RERR_UBTO|RERR_NCHN)) ||

                    len < ETHERMIN || len > ETHERMTU) {

                        ds->ds_if.if_ierrors++;

                        if (dedebug)

                        printf("de%d: ierror, flags=%b lenerr=%b
(len=%d)\n",

                                unit, rp->r_flags, RFLG_BITS, rp->r_lenerr,

                                RERR_BITS, len);

                } else

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

if_dereg.h:#define      RFLG_ERRS       0x40            /* Error summary */

if_dereg.h:#define      RFLG_FRAM       0x20            /* Framing error */

if_dereg.h:#define      RFLG_OFLO       0x10            /* Message overflow
*/

if_dereg.h:#define      RFLG_CRC        0x08            /* CRC error */

if_dereg.h:#define      RFLG_STP        0x02            /* Start of packet
*/

if_dereg.h:#define      RFLG_ENP        0x01            /* End of packet */

if_dereg.h:#define      RERR_BUFL       0x8000          /* Buffer length
error *

if_dereg.h:#define      RERR_UBTO       0x4000          /* UNIBUS tiemout */

if_dereg.h:#define      RERR_NCHN       0x2000          /* No data chaining
*/

 

 

Now I don't know if Ultrix still has the driver source code... but this was
a quick enough fix for me.  And I recall if_de.c being the same from 4.2BSD
into 4.3BSD as it was the same fix I used to get them all working on SIMH.

 

 

 

 

The patch was something like this...

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

500c500

<               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

---

> /***          if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

503a504,505

>                       ***/

>                       if(1==5){

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

 

  _____  

From: Henry Bent [mailto:hbent at oberlin.edu] 
Sent: Friday, June 27, 2014 9:09 AM
To: simh at trailing-edge.com
Subject: [Simh] Ultrix 1.0

 

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
on the MicroVAX 1 simulator.  It appears that the distribution there was
only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on
any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to
be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put
32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly,
albeit with quite a bit of disk swapping - the installation disk set is 13
floppies.

The QVSS is supported and will display some output on boot.  I haven't yet
looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references
to a qe device - but I can't figure out how to get it recognized.
Unfortunately there are no kernel config files in the distribution, so I
have no idea if the stock kernel is expecting the controller at a
non-standard address.  Any help with this would be greatly appreciated, 

-Henry

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

From dott.piergiorgio at fastwebnet.it  Fri Jun 27 04:24:02 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Fri, 27 Jun 2014 10:24:02 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <53AD2A22.7070609@fastwebnet.it>

Il 27/06/2014 03:09, Henry Bent ha scritto:
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,

After some misgivings, it actually works here !

(my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit 
id: 796cbd27)

Good work !

Best regards from Italy,
dott. Piergiorgio.


From Mark at infocomm.com  Fri Jun 27 07:01:19 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 04:01:19 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <53AD2A22.7070609@fastwebnet.it>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <53AD2A22.7070609@fastwebnet.it>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>

On Friday, June 27, 2014 at 1:24 AM, dott.Piergiorgio d' Errico wrote:
> Il 27/06/2014 03:09, Henry Bent ha scritto:
> > I had success booting the Unix Archive's floppy distribution of Ultrix 
> > 1.0 on the MicroVAX 1 simulator.  It appears that the distribution 
> > there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and 
> > will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, 
> > and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To 
> > boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on 
> > RQ2.  The install goes cleanly, albeit with quite a bit of disk 
> > swapping - the installation disk set is 13 floppies.
> >
> > The QVSS is supported and will display some output on boot.  I haven't 
> > yet looked into what is needed to use it as the console (if that's possible?).
> >
> > The kernel seems to support what I assume is the DEQNA - it has 
> > references to a qe device - but I can't figure out how to get it recognized.
> > Unfortunately there are no kernel config files in the distribution, so 
> > I have no idea if the stock kernel is expecting the controller at a 
> > non-standard address.  Any help with this would be greatly 
> > appreciated,
>
> After some misgivings, it actually works here !
>
> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)

Can you elaborate on the 'misgivings' or can you describe what 'works'?

Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip

Thanks.

- Mark


From david.hittner at ngc.com  Fri Jun 27 11:43:32 2014
From: david.hittner at ngc.com (Hittner, David T (IS))
Date: Fri, 27 Jun 2014 15:43:32 +0000
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>

AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in SIMH, unless someone has done it recently.
QVSS mono graphics and QDSS color graphics were supported on the MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690) series.
You?d have to map the graphics output to some fairly common graphics renderer for portability: X or QT are probably the best bets. X would be more universally available.

One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows, and I don?t think it was ever back-ported into the SIMH code base. It was based on an older SIMH 2.x release, I think.

I took a stab at writing the QDSS simulator using X once, but couldn?t find enough documentation to figure out what the QDSS card was doing. There?s a lot of weird pixel mapping going on.
I still have real QDSS boards in an  VAX 4000/500 to compare behavior with if anyone ever finds enough QDSS documentation for me.

--

Regarding the DEQNA ? there were some early DEQNA boards that had less bits defined in the registers. It?s possible that Ultrix 1.0 sees the ?wrong? register state - undefined bits shouldn?t be tested and verified, but in practice, most OS?s *assume* that the undefined bits will be in a specific state at specific times, and will exit if the undefined bits aren?t in the ?correct? state.

Dave

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 9:09 PM
To: simh at trailing-edge.com
Subject: EXT :[Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/9cef9fad/attachment.html>

From aek at bitsavers.org  Fri Jun 27 11:53:51 2014
From: aek at bitsavers.org (Al Kossow)
Date: Fri, 27 Jun 2014 08:53:51 -0700
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <53AD938F.3090802@bitsavers.org>

On 6/27/14 8:43 AM, Hittner, David T (IS) wrote:

> One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows

There has been a lot of work on the Rainbow in the past year in MESS.




From Mark at infocomm.com  Fri Jun 27 12:04:23 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 09:04:23 -0700
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2D@REDROOF2.alohasunset.com>

QVSS support was done by Matt Burke (as part of the extra VAX models he implemented) and has been in the MicroVAX I and MicroVAX II simulators available on github for at least a year.

The video support provided uses the video, keyboard and mouse capabilities provided by libSDL.

Since we?ve only got the mono graphics of the QVSS video to worry about now the necessary interfaces to provide color capabilities haven?t been fully worked out, but should be not too hard to work out when necessary.

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Hittner, David T (IS)
Sent: Friday, June 27, 2014 8:44 AM
To: Henry Bent
Cc: simh at trailing-edge.com
Subject: Re: [Simh] EXT : Ultrix 1.0

AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in SIMH, unless someone has done it recently.
QVSS mono graphics and QDSS color graphics were supported on the MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690) series.
You?d have to map the graphics output to some fairly common graphics renderer for portability: X or QT are probably the best bets. X would be more universally available.

One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows, and I don?t think it was ever back-ported into the SIMH code base. It was based on an older SIMH 2.x release, I think.

I took a stab at writing the QDSS simulator using X once, but couldn?t find enough documentation to figure out what the QDSS card was doing. There?s a lot of weird pixel mapping going on.
I still have real QDSS boards in an  VAX 4000/500 to compare behavior with if anyone ever finds enough QDSS documentation for me.

--

Regarding the DEQNA ? there were some early DEQNA boards that had less bits defined in the registers. It?s possible that Ultrix 1.0 sees the ?wrong? register state - undefined bits shouldn?t be tested and verified, but in practice, most OS?s *assume* that the undefined bits will be in a specific state at specific times, and will exit if the undefined bits aren?t in the ?correct? state.

Dave

From: simh-bounces at trailing-edge.com<mailto:simh-bounces at trailing-edge.com> [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 9:09 PM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: EXT :[Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/10351cd0/attachment-0001.html>

From tfmorris at gmail.com  Fri Jun 27 12:12:14 2014
From: tfmorris at gmail.com (Tom Morris)
Date: Fri, 27 Jun 2014 12:12:14 -0400
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>

The QVSS was a dumb frame buffer and would be pretty easy to emulate, but
the QDSS used the Dragon "accelerator" chip (or the "drag on" chip as it
was known at the time for its engineering schedule). Emulating the Dragon
behavior would likely be a lot more involved.

Tom


On Fri, Jun 27, 2014 at 11:43 AM, Hittner, David T (IS) <
david.hittner at ngc.com> wrote:

>  AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in
> SIMH, unless someone has done it recently.
>
> QVSS mono graphics and QDSS color graphics were supported on the MicroVAX
> 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690)
> series.
>
> You?d have to map the graphics output to some fairly common graphics
> renderer for portability: X or QT are probably the best bets. X would be
> more universally available.
>
>
>
> One of the 1-off simulators posted on the web really did simulate Rainbow
> or Pro350 graphics, but it only worked on windows, and I don?t think it was
> ever back-ported into the SIMH code base. It was based on an older SIMH 2.x
> release, I think.
>
>
>
> I took a stab at writing the QDSS simulator using X once, but couldn?t
> find enough documentation to figure out what the QDSS card was doing.
> There?s a lot of weird pixel mapping going on.
>
> I still have real QDSS boards in an  VAX 4000/500 to compare behavior with
> if anyone ever finds enough QDSS documentation for me.
>
>
>
> --
>
>
>
> Regarding the DEQNA ? there were some early DEQNA boards that had less
> bits defined in the registers. It?s possible that Ultrix 1.0 sees the
> ?wrong? register state - undefined bits shouldn?t be tested and verified,
> but in practice, most OS?s **assume** that the undefined bits will be in
> a specific state at specific times, and will exit if the undefined bits
> aren?t in the ?correct? state.
>
>
>
> Dave
>
>
>
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Henry Bent
> *Sent:* Thursday, June 26, 2014 9:09 PM
> *To:* simh at trailing-edge.com
> *Subject:* EXT :[Simh] Ultrix 1.0
>
>
>
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>
> -Henry
>
> _______________________________________________
> 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/20140627/f3746fe1/attachment.html>

From hoelscher-kirchbrak at freenet.de  Fri Jun 27 16:16:19 2014
From: hoelscher-kirchbrak at freenet.de (=?UTF-8?B?SGFucy1VbHJpY2ggSMO2bHNjaGVy?=)
Date: Fri, 27 Jun 2014 22:16:19 +0200
Subject: [Simh] Ultrix 1.0
Message-ID: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>

Henry,
I tried to reproduce your installation using your instructions, but I failed:

sim> b rq1
Loading boot code from ka610.bin
 2..1..0.
Boot
: ra(1,0)vmunix
186016+46652+44656 start 0x10bc
Ultrix-32m V1.0 System #1: Fri Aug 17 11:57:07 EDT 1984
real mem  = 4190208
avail mem = 3374080
using 110 buffers containing 418816 bytes of memory
MicroVAX 1, microcode level = 5
Q22 bus
rqd0 at bus0 csr 172150 vec 774, ipl 17
ra0 at rqd0 slave 0
ra1 at rqd0 slave 1
ra2 at rqd0 slave 2
dz0 at bus0 csr 160100 vec 300, ipl 17
dz1 at bus0 csr 160110 vec 310, ipl 17
trap type 9, code = 800a755c, pc = 80014ba7
panic: Protection fault
syncing disks... done
dumping to dev 901, offset 0
dump succeededLoading boot code from ka610.bin
Rebooting...
 2..1..0.
Boot
: ra(1,0)vmunix

Could you please give me your ini file just in case I missed something there?

Thanks!

P.S.
Your RD52 Image runs fine.
I have a real MicroVAX I, but unfortunately no RD52 :-((
By the way - I'm from Germany, too ...




---
Alle Postf?cher an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen



From hbent at oberlin.edu  Fri Jun 27 16:27:01 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Fri, 27 Jun 2014 16:27:01 -0400
Subject: [Simh] Ultrix 1.0
In-Reply-To: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
References: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
Message-ID: <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>

I don't have an ini file, I just save the state when I'm done and restore
it the next time.  I'm using the latest version from git, if that matters:

MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: f961a98b

I disabled everything I didn't need.  So I guess an ini file would be
something along the lines of:
set cpu idle=ultrixold
set tti 7b
set tto 7b
set cr disabled
set lpt disabled
set rl disabled
set rq0 rd52
set rq1 rx50
set rq2 rx50
set rq3 disabled
set ts disabled
set tq disabled
set xq type=deqna

-Henry




On 27 June 2014 16:16, Hans-Ulrich H?lscher <hoelscher-kirchbrak at freenet.de>
wrote:

> Henry,
> I tried to reproduce your installation using your instructions, but I
> failed:
>
> sim> b rq1
> Loading boot code from ka610.bin
>  2..1..0.
> Boot
> : ra(1,0)vmunix
> 186016+46652+44656 start 0x10bc
> Ultrix-32m V1.0 System #1: Fri Aug 17 11:57:07 EDT 1984
> real mem  = 4190208
> avail mem = 3374080
> using 110 buffers containing 418816 bytes of memory
> MicroVAX 1, microcode level = 5
> Q22 bus
> rqd0 at bus0 csr 172150 vec 774, ipl 17
> ra0 at rqd0 slave 0
> ra1 at rqd0 slave 1
> ra2 at rqd0 slave 2
> dz0 at bus0 csr 160100 vec 300, ipl 17
> dz1 at bus0 csr 160110 vec 310, ipl 17
> trap type 9, code = 800a755c, pc = 80014ba7
> panic: Protection fault
> syncing disks... done
> dumping to dev 901, offset 0
> dump succeededLoading boot code from ka610.bin
> Rebooting...
>  2..1..0.
> Boot
> : ra(1,0)vmunix
>
> Could you please give me your ini file just in case I missed something
> there?
>
> Thanks!
>
> P.S.
> Your RD52 Image runs fine.
> I have a real MicroVAX I, but unfortunately no RD52 :-((
> By the way - I'm from Germany, too ...
>
>
>
>
> ---
> Alle Postf?cher an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
> http://email.freenet.de/basic/Informationen
>
>
> _______________________________________________
> 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/20140627/9bedf1c7/attachment.html>

From Mark at infocomm.com  Fri Jun 27 22:54:22 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 19:54:22 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8014DA59283@REDROOF2.alohasunset.com>

Hi Jason,

This is interesting.

The 4.2 and 4.3BSD (and Ultrix) drivers MUST have worked with real hardware, so the best course of action here would be to fix the simulation to match what the software expects.

The code you're pointing at below (if_de.c) is the driver for the DEUNA/DELUA not the DEQNA which the original poster is using.

I could believe that there are issues with the DEUNA implementation for earlier Ultrix and BSD versions.  I'm glad to fix that also if the simulated hardware isn't consistent with how real hardware worked...

Can you remember or better yet, provide a specific case which needs the driver patch you suggest below...

Thanks.


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Jason Stevens
Sent: Thursday, June 26, 2014 7:35 PM
To: 'Henry Bent'; simh at trailing-edge.com
Subject: Re: [Simh] Ultrix 1.0

I wonder if it's related to the BSD driver for the network card.... Years ago I was playing with 4.2 and 4.3BSD and I never could get the network card to work, so I started to play with the driver, and I found this:

In the  if_de.c driver there is some error checking, that always seems to come back with errors.

------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
/*
 * Ethernet interface receiver interface.
 * If input error just drop packet.
 * Otherwise purge input buffered data path and examine
 * packet to determine type.  If can't determine length
 * from type, then have to drop packet.  Othewise decapsulate
 * packet based on type and pass to type specific higher-level
 * input routine.
 */
derecv(unit)
        int unit;
{
        register struct de_softc *ds = &de_softc[unit];
        register struct de_ring *rp;
        int len;

        rp = &ds->ds_rrent[ds->ds_rindex];
        while ((rp->r_flags & RFLG_OWN) == 0) {
                ds->ds_if.if_ipackets++;
                if (ds->ds_deuba.iff_flags & UBA_NEEDBDP)
                        UBAPURGE(ds->ds_deuba.iff_uba,
                        ds->ds_ifr[ds->ds_rindex].ifrw_bdp);
                len = (rp->r_lenerr&RERR_MLEN) - sizeof (struct ether_header)
                        - 4;    /* don't forget checksum! */
                /* check for errors */
               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
                    (rp->r_flags&(RFLG_STP|RFLG_ENP)) != (RFLG_STP|RFLG_ENP) ||
                    (rp->r_lenerr & (RERR_BUFL|RERR_UBTO|RERR_NCHN)) ||
                    len < ETHERMIN || len > ETHERMTU) {
                        ds->ds_if.if_ierrors++;
                        if (dedebug)
                        printf("de%d: ierror, flags=%b lenerr=%b (len=%d)\n",
                                unit, rp->r_flags, RFLG_BITS, rp->r_lenerr,
                                RERR_BITS, len);
                } else
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
if_dereg.h:#define      RFLG_ERRS       0x40            /* Error summary */
if_dereg.h:#define      RFLG_FRAM       0x20            /* Framing error */
if_dereg.h:#define      RFLG_OFLO       0x10            /* Message overflow */
if_dereg.h:#define      RFLG_CRC        0x08            /* CRC error */
if_dereg.h:#define      RFLG_STP        0x02            /* Start of packet */
if_dereg.h:#define      RFLG_ENP        0x01            /* End of packet */
if_dereg.h:#define      RERR_BUFL       0x8000          /* Buffer length error *
if_dereg.h:#define      RERR_UBTO       0x4000          /* UNIBUS tiemout */
if_dereg.h:#define      RERR_NCHN       0x2000          /* No data chaining */


Now I don't know if Ultrix still has the driver source code... but this was a quick enough fix for me.  And I recall if_de.c being the same from 4.2BSD into 4.3BSD as it was the same fix I used to get them all working on SIMH.




The patch was something like this...
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
500c500
<               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
---
> /***          if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
503a504,505
>                       ***/
>                       if(1==5){
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<

________________________________
From: Henry Bent [mailto:hbent at oberlin.edu]
Sent: Friday, June 27, 2014 9:09 AM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: [Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/eeb46e1e/attachment-0001.html>

From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:25:00 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:25:00 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <53AD2A22.7070609@fastwebnet.it>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>
Message-ID: <53AE7BDC.2030407@fastwebnet.it>

Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:

>> After some misgivings, it actually works here !
>>
>> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)
>
> Can you elaborate on the 'misgivings' or can you describe what 'works'?

my mistakes in configuring from the printout of sh con given by Henry 
Bent...


> Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip

Either I can't have figured how to set some params, or perhaps was 
implemented but not settable back then; in particular, I can't set, or 
don't get how to set "vector=HHH" but ULTRIX booted and I can do simple 
quick testing with "no vector" in the configuration (ls, cat |more and 
like, I live in southern Italy, and the overheating of actual hardware 
IS an issue for me; if you want that I do more specific looking in 
depth, I'll try to do this during the night....)

Best regards from Italy,
dott. Piergiorgio.


From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:29:56 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:29:56 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>
References: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
 <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>
Message-ID: <53AE7D04.80500@fastwebnet.it>

Il 27/06/2014 22:27, Henry Bent ha scritto:
> I don't have an ini file, I just save the state when I'm done and restore
> it the next time.  I'm using the latest version from git, if that matters:
>
> MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: f961a98b
>
> I disabled everything I didn't need.  So I guess an ini file would be
> something along the lines of:
> set cpu idle=ultrixold
> set tti 7b
> set tto 7b
> set cr disabled
> set lpt disabled
> set rl disabled
> set rq0 rd52
> set rq1 rx50
> set rq2 rx50
> set rq3 disabled
> set ts disabled
> set tq disabled
> set xq type=deqna

I fully confirm this, it is how I have booted ultrix on a 1 yrs ago old 
build of SIMH 4 beta....

Best regards from Italy,
dott. Piergiorgio.



From Mark at infocomm.com  Sat Jun 28 04:37:27 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sat, 28 Jun 2014 01:37:27 -0700
Subject: [Simh] Ultrix 1.0
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>


On Jun 28, 2014 1:25 AM, "dott.Piergiorgio d' Errico" <dott.piergiorgio at fastwebnet.it> wrote:
>
> Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:
>
> >> After some misgivings, it actually works here !
> >>
> >> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)
> >
> > Can you elaborate on the 'misgivings' or can you describe what 'works'?
>
> my mistakes in configuring from the printout of sh con given by Henry
> Bent...

So, what you mean is that you can boot Henry's disk in the simulator, not that when you boot it networking 'works'.  Right??

> > Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip
>
> Either I can't have figured how to set some params, or perhaps was
> implemented but not settable back then; in particular, I can't set, or
> don't get how to set "vector=HHH" but ULTRIX booted and I can do simple
> quick testing with "no vector" in the configuration (ls, cat |more and
> like, I live in southern Italy, and the overheating of actual hardware
> IS an issue for me; if you want that I do more specific looking in
> depth, I'll try to do this during the night....)

The DEQNA device does not have a vector set by switches.  The vector is set programmatically by the device driver.  This is also true for the RQ (MSCP) and TQ (TMSCP) devices as well.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140628/cd0b0753/attachment.html>

From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:52:31 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:52:31 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>
References: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>
Message-ID: <53AE824F.4050309@fastwebnet.it>

Il 28/06/2014 10:37, Mark Pizzolato - Info Comm ha scritto:
> So, what you mean is that you can boot Henry's disk in the simulator, not that when you boot it networking 'works'.  Right??

no, that I initially don't get right how to convert the sh con output 
into actual simh commands... pls notice that when I wrote "misgivings" I 
always refer to human erring, not machine errors....

Best regards from Italy,
dott. Piergiorgio.


From matt at 9track.net  Sat Jun 28 19:52:16 2014
From: matt at 9track.net (Matt Burke)
Date: Sun, 29 Jun 2014 00:52:16 +0100
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
 <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>
Message-ID: <53AF5530.8030608@9track.net>

That's right, the QVSS wasn't too bad to implement once I worked out how
to handle the scan-line map and the cursor overlay.

I've partly implemented the QDSS, but it's very complicated. The host
does not have direct access to the frame buffer as with the QVSS. There
is an "Adder" address processor that handles the movement of data
between the QBus and the frame buffer. The "Adder" also transfers
commands or "rasterops" to the 4 or 8 "Viper" video processors, each of
which manipulate 1 plane of data in the frame buffer. Each plane can be
individually stretched, skewed, rotated etc. by these processors.

There's enough documentation available to do this, but given the
complexity I don't think it will get finished any time soon. You can see
some of the progress with Simh video here:

http://9track.net/simh/video/

Matt

On 27/06/2014 17:12, Tom Morris wrote:
> The QVSS was a dumb frame buffer and would be pretty easy to emulate,
> but the QDSS used the Dragon "accelerator" chip (or the "drag on" chip
> as it was known at the time for its engineering schedule). Emulating
> the Dragon behavior would likely be a lot more involved.
>
> Tom
>
>
> On Fri, Jun 27, 2014 at 11:43 AM, Hittner, David T (IS)
> <david.hittner at ngc.com <mailto:david.hittner at ngc.com>> wrote:
>
>     AFAIK, the Q-Bus QVSS graphic video card(s) have not been
>     simulated in SIMH, unless someone has done it recently.
>
>     QVSS mono graphics and QDSS color graphics were supported on the
>     MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and
>     VAX 4000 (KA670/690) series.
>
>     You'd have to map the graphics output to some fairly common
>     graphics renderer for portability: X or QT are probably the best
>     bets. X would be more universally available.
>
>      
>
>     One of the 1-off simulators posted on the web really did simulate
>     Rainbow or Pro350 graphics, but it only worked on windows, and I
>     don't think it was ever back-ported into the SIMH code base. It
>     was based on an older SIMH 2.x release, I think.
>
>      
>
>     I took a stab at writing the QDSS simulator using X once, but
>     couldn't find enough documentation to figure out what the QDSS
>     card was doing. There's a lot of weird pixel mapping going on.
>
>     I still have real QDSS boards in an  VAX 4000/500 to compare
>     behavior with if anyone ever finds enough QDSS documentation for me.
>
>      
>
>     --
>
>      
>
>     Regarding the DEQNA -- there were some early DEQNA boards that had
>     less bits defined in the registers. It's possible that Ultrix 1.0
>     sees the 'wrong' register state - undefined bits shouldn't be
>     tested and verified, but in practice, most OS's **assume** that
>     the undefined bits will be in a specific state at specific times,
>     and will exit if the undefined bits aren't in the 'correct' state.
>
>      
>
>     Dave
>
>      
>
>     *From:*simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>
>     [mailto:simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>] *On Behalf Of *Henry Bent
>     *Sent:* Thursday, June 26, 2014 9:09 PM
>     *To:* simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>     *Subject:* EXT :[Simh] Ultrix 1.0
>
>      
>
>     I had success booting the Unix Archive's floppy distribution of
>     Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the
>     distribution there was only meant for a dual-RX50 MicroVAX 1 with
>     an RD drive, and will not boot on any other machine.  RQ0 needs to
>     be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO
>     need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on
>     RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit
>     with quite a bit of disk swapping - the installation disk set is
>     13 floppies.
>
>     The QVSS is supported and will display some output on boot.  I
>     haven't yet looked into what is needed to use it as the console
>     (if that's possible?).
>
>     The kernel seems to support what I assume is the DEQNA - it has
>     references to a qe device - but I can't figure out how to get it
>     recognized.  Unfortunately there are no kernel config files in the
>     distribution, so I have no idea if the stock kernel is expecting
>     the controller at a non-standard address.  Any help with this
>     would be greatly appreciated,
>
>     -Henry
>
>
>     _______________________________________________
>     Simh mailing list
>     Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>     http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> 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/20140629/de990924/attachment-0001.html>

From b4 at gewt.net  Sun Jun 29 07:11:51 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 29 Jun 2014 07:11:51 -0400 (Eastern Daylight Time)
Subject: [Simh] PCL-11?
Message-ID: <alpine.WNT.2.01.1406290709160.3040@melanie.gimme-sympathy.org>

Hello,

Does anyone know anything about the PCL-11 communications stuff and have 
any plans to implement it?  I can't find too much about it in a quick 
20-second look, others will likely fare better.

Also: 32V, 3BSD, and System III do not boot in SIMH 3.9 and above.  They 
boot fine in 3.8-1, however.  They throw a kernel trap.  I can't share the 
SysIII obviously...but I can boot any changes for testing.  3BSD and 32V 
will likely be the same.

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

From frisbie at flying-disk.com  Sun Jun 29 12:32:58 2014
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Sun, 29 Jun 2014 09:32:58 -0700 (PDT)
Subject: [Simh] PCL-11?
Message-ID: <14062909325846_448@slug.flying-disk.com>


> Does anyone know anything about the PCL-11 communications stuff
> and have any plans to implement it?  I can't find too much about
> it in a quick 20-second look, others will likely fare better.

I used it on both PDP-11/44 (RSX-11M+) and VAX/780 (VMS) systems
back in the early 1980s.   I even had to work on the VMS device
driver so that DECnet would work.

Unfortunately, I don't have any of the documentation or code from
those projects.   Just the memory that Field Service had a
terrible time adjusting the PCL bus timing so that they would
work.   Those wide cables were not pleasant to work with.

If you have any specific questions, it might jog some dusty bits
loose in my mind.

Alan Frisbie

From gltmailbox-simh at yahoo.com  Sun Jun 29 22:14:38 2014
From: gltmailbox-simh at yahoo.com (Galen Tackett)
Date: Sun, 29 Jun 2014 22:14:38 -0400
Subject: [Simh] PCL-11?
In-Reply-To: <14062909325846_448@slug.flying-disk.com>
References: <14062909325846_448@slug.flying-disk.com>
Message-ID: <29022CB1-C4BE-4778-BD45-71BB6B69CB52@yahoo.com>


> 
>> Does anyone know anything about the PCL-11 communications stuff
>> and have any plans to implement it?  I can't find too much about
>> it in a quick 20-second look, others will likely fare better.
> 
> I used it on both PDP-11/44 (RSX-11M+) and VAX/780 (VMS) systems
> back in the early 1980s.   I even had to work on the VMS device
> driver so that DECnet would work.
> 
What was the PCL-11? I?m trying to remember if I ever encountered one. (I wouldn?t have anything helpful to offer, I?m afraid?just reminiscing.)

One device I spent a lot of time with, my first year out of college, was the DA-11B, a memory to memory DMA link which we used at Lockheed between several LSI-11 data collection stations running RSX-11S and a PDP-11/60 with RSX-11M that ran a static load test system for us. There were no device drivers for it, or at least none suitable for this purpose, so I wrote the link software we used?partly in Macro-11, of course, but also partly using DECUS C.

A coworker of mine had found a way to use the Connect to Interrupt Vector directive (CINT$) with a program that was mostly in FORTRAN, using some linkage code in Macro. I turned this into something similar for use with DECUS C.

We used a differential-signal version of the DA-11 (maybe that?s what the -B was for?) to go the relatively long distance (for DMA, in those days) from four locations on our big 7 story test stand, into the small computer room located off the 2nd or 4th floor--I forget which for certain, but our office was a room two stories up from that.

As I recall, our DEC Field Service rep. had a bit of work to do, to get this hardware working reliably. There may have been problems involving the flat, wide-ish cables that before installation had been pre-pulled through the trays on the test stand. Perhaps grounding issues?

That was a fun project and a nice challenge right out of college. I constantly had my hands on/in both hardware and software. Ah, the memories...

From quentin at quentin.org.uk  Tue Jun 10 06:28:25 2014
From: quentin at quentin.org.uk (Quentin North)
Date: Tue, 10 Jun 2014 11:28:25 +0100
Subject: [Simh] Principal vintage software developer
In-Reply-To: <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
Message-ID: <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>

I saw this job advertised in Seattle which may be of interest to members of the list

http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job

Brush off your PDP and CDC skills. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140610/107af00c/attachment-0002.html>

From aek at bitsavers.org  Tue Jun 10 09:13:58 2014
From: aek at bitsavers.org (Al Kossow)
Date: Tue, 10 Jun 2014 06:13:58 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
Message-ID: <53970496.1050909@bitsavers.org>

On 6/10/14 3:28 AM, Quentin North wrote:
> I saw this job advertised in Seattle which may be of interest to members of the list
>
> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>
> Brush off your PDP and CDC skills.
>

I would suggest emailing Ian King before considering a job there.





From phiber at phiber.com  Tue Jun 10 18:33:05 2014
From: phiber at phiber.com (Mark Abene)
Date: Tue, 10 Jun 2014 15:33:05 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <53970496.1050909@bitsavers.org>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
Message-ID: <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>

...and getting fitted for a kilt.



On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:

> On 6/10/14 3:28 AM, Quentin North wrote:
>
>> I saw this job advertised in Seattle which may be of interest to members
>> of the list
>>
>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>>
>> Brush off your PDP and CDC skills.
>>
>>
> I would suggest emailing Ian King before considering a job there.
>
>
>
> _______________________________________________
> 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/20140610/e3346c6c/attachment-0002.html>

From b4 at gewt.net  Mon Jun 16 02:11:50 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 02:11:50 -0400 (EDT)
Subject: [Simh] VAX-11/780 simulator: rx device
Message-ID: <alpine.OSX.2.00.1406160209260.15321@melanie.local>

Hello all,

What happened to the RX device in the VAX simulators?  I see the source 
file is still there...but it's been removed from the makefile.

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From b4 at gewt.net  Mon Jun 16 02:44:19 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Mon, 16 Jun 2014 02:44:19 -0400 (EDT)
Subject: [Simh] VAX-11/780 simulator: rx device
In-Reply-To: <alpine.OSX.2.00.1406160209260.15321@melanie.local>
References: <alpine.OSX.2.00.1406160209260.15321@melanie.local>
Message-ID: <alpine.OSX.2.00.1406160243590.15321@melanie.local>

On Mon, 16 Jun 2014, Cory Smelosky wrote:

> Hello all,
>
> What happened to the RX device in the VAX simulators?  I see the source file 
> is still there...but it's been removed from the makefile.
>

Ahh.  It got renamed to CS from RX.  Makes sense.

Please remove the volume "eeeeeeeeeeee" from the console device

Now I can proceed. ;)

>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From simh at alderson.users.panix.com  Mon Jun 16 20:06:02 2014
From: simh at alderson.users.panix.com (Rich Alderson)
Date: Mon, 16 Jun 2014 20:06:02 -0400 (EDT)
Subject: [Simh] Principal vintage software developer
In-Reply-To: <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 (message from Mark Abene on Tue, 10 Jun 2014 15:33:05 -0700)
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
Message-ID: <20140617000602.E0614242E4@panix5.panix.com>

> Date: Tue, 10 Jun 2014 15:33:05 -0700
> From: Mark Abene <phiber at phiber.com>

> On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:

>> On 6/10/14 3:28 AM, Quentin North wrote:

>>> I saw this job advertised in Seattle which may be of interest to members
>>> of the list

>>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job

>>> Brush off your PDP and CDC skills.

>> I would suggest emailing Ian King before considering a job there.

> ...and getting fitted for a kilt.

Ian was the only person at LCM who wore a kilt; it's not a job requirement.

I won't try to speak for Ian, but I will point out that he posted a defense of
the job listing (as did Mike Ross) at The Register when commentors on this same
listing took cheap shots at it based on no information.

http://www.theregister.co.uk/2014/06/10/vintage_coder_remember_control_data_the_lcm_wants_you/

Feel free to ask me about it, too.  I won't lie about it.  I am, after all, in
the same job as Ian was and I've been here 5 years longer.  (I interviewed Ian
for the job.)

                                                                Rich


From phiber at phiber.com  Tue Jun 17 02:18:33 2014
From: phiber at phiber.com (Mark Abene)
Date: Mon, 16 Jun 2014 23:18:33 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <20140617000602.E0614242E4@panix5.panix.com>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
Message-ID: <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>

The kilt reference is what we call a "joke".
If I wore a giant sombrero to work, it would no doubt be all over the
Internet.
There is still humor left in the world, I'm sure of it.



On Mon, Jun 16, 2014 at 5:06 PM, Rich Alderson <
simh at alderson.users.panix.com> wrote:

> > Date: Tue, 10 Jun 2014 15:33:05 -0700
> > From: Mark Abene <phiber at phiber.com>
>
> > On Tue, Jun 10, 2014 at 6:13 AM, Al Kossow <aek at bitsavers.org> wrote:
>
> >> On 6/10/14 3:28 AM, Quentin North wrote:
>
> >>> I saw this job advertised in Seattle which may be of interest to
> members
> >>> of the list
>
> >>> http://www.vulcan.com/About/Job-Listings?jvi=oTAQYfw1,Job
>
> >>> Brush off your PDP and CDC skills.
>
> >> I would suggest emailing Ian King before considering a job there.
>
> > ...and getting fitted for a kilt.
>
> Ian was the only person at LCM who wore a kilt; it's not a job requirement.
>
> I won't try to speak for Ian, but I will point out that he posted a
> defense of
> the job listing (as did Mike Ross) at The Register when commentors on this
> same
> listing took cheap shots at it based on no information.
>
>
> http://www.theregister.co.uk/2014/06/10/vintage_coder_remember_control_data_the_lcm_wants_you/
>
> Feel free to ask me about it, too.  I won't lie about it.  I am, after
> all, in
> the same job as Ian was and I've been here 5 years longer.  (I interviewed
> Ian
> for the job.)
>
>                                                                 Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140616/d45dade8/attachment-0002.html>

From simh at alderson.users.panix.com  Tue Jun 17 15:14:28 2014
From: simh at alderson.users.panix.com (Rich Alderson)
Date: Tue, 17 Jun 2014 15:14:28 -0400 (EDT)
Subject: [Simh] Principal vintage software developer
In-Reply-To: <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 (message from Mark Abene on Mon, 16 Jun 2014 23:18:33 -0700)
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
Message-ID: <20140617191428.D92C9242E3@panix5.panix.com>

> Date: Mon, 16 Jun 2014 23:18:33 -0700
> From: Mark Abene <phiber at phiber.com>

> The kilt reference is what we call a "joke".
> If I wore a giant sombrero to work, it would no doubt be all over the
> Internet.

I knew it was a joke, or I'd not have addressed it.

But my friend Al was not joking.  Things were briefly bad in the umbrella
organization that pays the engineering staff at the museum, and Ian and I
got caught in that.  It's no longer a problem, but we lost Ian because of
it.

> There is still humor left in the world, I'm sure of it.

Oh, there is.  Trouble is, some of the wounds are still salty.

                                                                Rich


From aek at bitsavers.org  Tue Jun 17 16:26:34 2014
From: aek at bitsavers.org (Al Kossow)
Date: Tue, 17 Jun 2014 13:26:34 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <20140617191428.D92C9242E3@panix5.panix.com>
References: <2070758.hMozsa9Jsr@lobster>	<69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>	<DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>	<53970496.1050909@bitsavers.org>	<CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>	<20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 <20140617191428.D92C9242E3@panix5.panix.com>
Message-ID: <53A0A47A.30702@bitsavers.org>

On 6/17/14 12:14 PM, Rich Alderson wrote:
> Things were briefly bad in the umbrella
> organization that pays the engineering staff at the museum, and Ian and I
> got caught in that.  It's no longer a problem, but we lost Ian because of
> it.
>

It's good to hear things are better now.





From phiber at phiber.com  Wed Jun 18 22:14:05 2014
From: phiber at phiber.com (Mark Abene)
Date: Wed, 18 Jun 2014 19:14:05 -0700
Subject: [Simh] Principal vintage software developer
In-Reply-To: <53A0A47A.30702@bitsavers.org>
References: <2070758.hMozsa9Jsr@lobster>
 <69EE207D-AF4F-4893-B835-60823785EBF9@quentin.org.uk>
 <DB9834A8-03C4-4134-B4D2-0130C0F64693@quentin.org.uk>
 <53970496.1050909@bitsavers.org>
 <CAPCE1iazNFPy2sZ0wV4BJ26HV4=ysM=t3P3gQHr+S0JkSvti8w@mail.gmail.com>
 <20140617000602.E0614242E4@panix5.panix.com>
 <CAPCE1ibzPx7+1RxKo-TWOt=p+5-u02_aQMhR6G8JQFB0s5PmQg@mail.gmail.com>
 <20140617191428.D92C9242E3@panix5.panix.com>
 <53A0A47A.30702@bitsavers.org>
Message-ID: <CAPCE1iZQ4qjOXjLHJnDiSb+j8gfF7GaHims4W8TYcWZosU+V3Q@mail.gmail.com>

I've been an XKLeTen user for a bunch of years, so it would definitely be
uncool if this and other museum awesomeness were negatively affected by a
billion-dollar parent company not allocating enough budget to the right
people.




On Tue, Jun 17, 2014 at 1:26 PM, Al Kossow <aek at bitsavers.org> wrote:

> On 6/17/14 12:14 PM, Rich Alderson wrote:
>
>> Things were briefly bad in the umbrella
>> organization that pays the engineering staff at the museum, and Ian and I
>> got caught in that.  It's no longer a problem, but we lost Ian because of
>> it.
>>
>>
> It's good to hear things are better now.
>
>
>
>
> _______________________________________________
> 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/20140618/9afacfff/attachment-0002.html>

From hbent at oberlin.edu  Thu Jun 26 21:09:10 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Thu, 26 Jun 2014 21:09:10 -0400
Subject: [Simh] Ultrix 1.0
Message-ID: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
on the MicroVAX 1 simulator.  It appears that the distribution there was
only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
cleanly, albeit with quite a bit of disk swapping - the installation disk
set is 13 floppies.

The QVSS is supported and will display some output on boot.  I haven't yet
looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references
to a qe device - but I can't figure out how to get it recognized.
Unfortunately there are no kernel config files in the distribution, so I
have no idea if the stock kernel is expecting the controller at a
non-standard address.  Any help with this would be greatly appreciated,

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/6d763bbe/attachment-0002.html>

From b4 at gewt.net  Thu Jun 26 21:19:03 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 26 Jun 2014 21:19:03 -0400 (Eastern Daylight Time)
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <alpine.WNT.2.01.1406262118310.3040@melanie.gimme-sympathy.org>

On Thu, 26 Jun 2014, Henry Bent wrote:

> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>

I'd take a look...but the MVI simulator will build but not run for me. :( 
I need to debug further and see if it was OS-specific.

> -Henry
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From hbent at oberlin.edu  Thu Jun 26 21:28:51 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Thu, 26 Jun 2014 21:28:51 -0400
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>
Message-ID: <CAKJ3OjnK2fyRK8EQ9MaUnu8MvCpuYwd1+9POxXXGqO9UfYZ71A@mail.gmail.com>

Thanks for the info, I've never worked with physical VAX hardware this
old.  The kernel is definitely accessing the DEQNA, here's what the debug
output shows during boot:

DBG(21694666)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0)
DBG(21694666)> XQ REG:    data=0xFF08
DBG(21694681)> XQ REG: xq_wr(data=0x00000002, PA=0x2000192E[CSR], access=2)
DBG(21694681)> XQ REG: xq_wr_csr(data=0x00000002)
DBG(21694684)> XQ REG: xq_wr(data=0x000001F8, PA=0x2000192C[VAR], access=2)
DBG(21694684)> XQ REG: xq_wr_var(data= 0x000001F8)
DBG(21694766)> XQ REG: xq_rd(PA=0x20001920 [MAC0], access=0)
DBG(21694766)> XQ REG:    data=0xFF08
DBG(21694769)> XQ REG: xq_rd(PA=0x20001922 [MAC1], access=0)
DBG(21694769)> XQ REG:    data=0xFF00
DBG(21694772)> XQ REG: xq_rd(PA=0x20001924 [MAC2], access=0)
DBG(21694772)> XQ REG:    data=0xFF2B
DBG(21694775)> XQ REG: xq_rd(PA=0x20001926 [MAC3], access=0)
DBG(21694775)> XQ REG:    data=0xFFAA
DBG(21694778)> XQ REG: xq_rd(PA=0x20001928 [MAC4], access=0)
DBG(21694778)> XQ REG:    data=0xFFBB
DBG(21694781)> XQ REG: xq_rd(PA=0x2000192A [MAC5], access=0)
DBG(21694781)> XQ REG:    data=0xFFCC
DBG(21695029)> XQ REG: xq_wr(data=0x000080C0, PA=0x2000192E[CSR], access=2)
DBG(21695029)> XQ REG: xq_wr_csr(data=0x000080C0)
DBG(21695031)> XQ REG: xq_wr(data=0x00001E78, PA=0x20001924[RBDL-Lo],
access=2)
DBG(21695034)> XQ REG: xq_wr(data=0x00000004, PA=0x20001926[RBDL-Hi],
access=2)
DBG(21695037)> XQ REG: xq_wr(data=0x00002158, PA=0x20001928[XBDL-Lo],
access=2)
DBG(21695041)> XQ REG: xq_wr(data=0x00000004, PA=0x2000192A[XBDL-Hi],
access=2)

I uploaded the RD52 image and the output of "sh c" here, anyone is welcome
to use it for whatever:
http://cs.oberlin.edu/~hbent/vaxultrix/ultrix1.tar.bz2

-Henry


On 26 June 2014 21:16, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:

> Hi Henry,
>
>
>
> There are only two possible addresses for a DEQNA device, and I’m very
> sure that the expected address is the primary address which should be the
> default.
>
>
>
> You can verify that the kernel is attempting to touch the Qbus register
> space for the DEQNA device with the following simh commands added to your
> simh configuration:
>
>
>
>     sim> set xq debug=REG
>
>     sim> set debug stdout
>
>
>
> Boot the simulator and the debug output should show any register
> references which may be occurring.
>
>
>
> If you truly believe that the DEQNA device isn’t working properly I can
> dig into the details if you can provide an RD51 or RD52 disk image and the
> configuration file you’re working with.
>
>
>
> Good Luck,
>
>
>
> -          Mark
>
>
>
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Henry Bent
> *Sent:* Thursday, June 26, 2014 6:09 PM
> *To:* simh at trailing-edge.com
> *Subject:* [Simh] Ultrix 1.0
>
>
>
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>
> -Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/0e0f3c9d/attachment-0002.html>

From Mark at infocomm.com  Thu Jun 26 21:16:38 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Thu, 26 Jun 2014 18:16:38 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC1F@REDROOF2.alohasunset.com>

Hi Henry,

There are only two possible addresses for a DEQNA device, and I’m very sure that the expected address is the primary address which should be the default.

You can verify that the kernel is attempting to touch the Qbus register space for the DEQNA device with the following simh commands added to your simh configuration:

    sim> set xq debug=REG
    sim> set debug stdout

Boot the simulator and the debug output should show any register references which may be occurring.

If you truly believe that the DEQNA device isn’t working properly I can dig into the details if you can provide an RD51 or RD52 disk image and the configuration file you’re working with.

Good Luck,


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 6:09 PM
To: simh at trailing-edge.com
Subject: [Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140626/14ad4cdf/attachment-0002.html>

From b4 at gewt.net  Thu Jun 26 21:33:46 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 26 Jun 2014 21:33:46 -0400 (Eastern Daylight Time)
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC20@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <alpine.WNT.2.01.1406262118310.3040@melanie.gimme-sympathy.org>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC20@REDROOF2.alohasunset.com>
Message-ID: <alpine.WNT.2.01.1406262132400.3040@melanie.gimme-sympathy.org>

On Thu, 26 Jun 2014, Mark Pizzolato - Info Comm wrote:

> Hi Cory,
>
> On Thursday, June 26, 2014 at 6:19 PM, Cory Smelosky wrote:
>> I'd take a look...but the MVI simulator will build but not run for me. :( I need
>> to debug further and see if it was OS-specific.
>
> What platform are you doing this on?
>

OS X Mavericks/Yosemite.  Unfortunately as a result of (unrelated) anger 
the disk was wiped.  I can get access to a friend's box, though.

And...apparently my email to you is "unsolicited" despite me being listed 
on 0 blacklists I know of...

> Thanks.
>
> - Mark
>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From jsteve at superglobalmegacorp.com  Thu Jun 26 22:35:15 2014
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Fri, 27 Jun 2014 10:35:15 +0800
Subject: [Simh] Ultrix 1.0
Message-ID: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>

I wonder if it's related to the BSD driver for the network card.... Years
ago I was playing with 4.2 and 4.3BSD and I never could get the network card
to work, so I started to play with the driver, and I found this:

 

In the  if_de.c driver there is some error checking, that always seems to
come back with errors.

 

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

/*

 * Ethernet interface receiver interface.

 * If input error just drop packet.

 * Otherwise purge input buffered data path and examine

 * packet to determine type.  If can't determine length

 * from type, then have to drop packet.  Othewise decapsulate

 * packet based on type and pass to type specific higher-level

 * input routine.

 */

derecv(unit)

        int unit;

{

        register struct de_softc *ds = &de_softc[unit];

        register struct de_ring *rp;

        int len;

 

        rp = &ds->ds_rrent[ds->ds_rindex];

        while ((rp->r_flags & RFLG_OWN) == 0) {

                ds->ds_if.if_ipackets++;

                if (ds->ds_deuba.iff_flags & UBA_NEEDBDP)

                        UBAPURGE(ds->ds_deuba.iff_uba,

                        ds->ds_ifr[ds->ds_rindex].ifrw_bdp);

                len = (rp->r_lenerr&RERR_MLEN) - sizeof (struct
ether_header)

                        - 4;    /* don't forget checksum! */

                /* check for errors */

               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

                    (rp->r_flags&(RFLG_STP|RFLG_ENP)) != (RFLG_STP|RFLG_ENP)
||

                    (rp->r_lenerr & (RERR_BUFL|RERR_UBTO|RERR_NCHN)) ||

                    len < ETHERMIN || len > ETHERMTU) {

                        ds->ds_if.if_ierrors++;

                        if (dedebug)

                        printf("de%d: ierror, flags=%b lenerr=%b
(len=%d)\n",

                                unit, rp->r_flags, RFLG_BITS, rp->r_lenerr,

                                RERR_BITS, len);

                } else

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

if_dereg.h:#define      RFLG_ERRS       0x40            /* Error summary */

if_dereg.h:#define      RFLG_FRAM       0x20            /* Framing error */

if_dereg.h:#define      RFLG_OFLO       0x10            /* Message overflow
*/

if_dereg.h:#define      RFLG_CRC        0x08            /* CRC error */

if_dereg.h:#define      RFLG_STP        0x02            /* Start of packet
*/

if_dereg.h:#define      RFLG_ENP        0x01            /* End of packet */

if_dereg.h:#define      RERR_BUFL       0x8000          /* Buffer length
error *

if_dereg.h:#define      RERR_UBTO       0x4000          /* UNIBUS tiemout */

if_dereg.h:#define      RERR_NCHN       0x2000          /* No data chaining
*/

 

 

Now I don't know if Ultrix still has the driver source code... but this was
a quick enough fix for me.  And I recall if_de.c being the same from 4.2BSD
into 4.3BSD as it was the same fix I used to get them all working on SIMH.

 

 

 

 

The patch was something like this...

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

500c500

<               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

---

> /***          if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC))
||

503a504,505

>                       ***/

>                       if(1==5){

------8<------8<------8<------8<------8<------8<------8<------8<------8<----
--8<

 

  _____  

From: Henry Bent [mailto:hbent at oberlin.edu] 
Sent: Friday, June 27, 2014 9:09 AM
To: simh at trailing-edge.com
Subject: [Simh] Ultrix 1.0

 

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
on the MicroVAX 1 simulator.  It appears that the distribution there was
only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on
any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to
be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put
32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly,
albeit with quite a bit of disk swapping - the installation disk set is 13
floppies.

The QVSS is supported and will display some output on boot.  I haven't yet
looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references
to a qe device - but I can't figure out how to get it recognized.
Unfortunately there are no kernel config files in the distribution, so I
have no idea if the stock kernel is expecting the controller at a
non-standard address.  Any help with this would be greatly appreciated, 

-Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/951fbf52/attachment-0002.html>

From dott.piergiorgio at fastwebnet.it  Fri Jun 27 04:24:02 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Fri, 27 Jun 2014 10:24:02 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <53AD2A22.7070609@fastwebnet.it>

Il 27/06/2014 03:09, Henry Bent ha scritto:
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,

After some misgivings, it actually works here !

(my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit 
id: 796cbd27)

Good work !

Best regards from Italy,
dott. Piergiorgio.



From Mark at infocomm.com  Fri Jun 27 07:01:19 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 04:01:19 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <53AD2A22.7070609@fastwebnet.it>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <53AD2A22.7070609@fastwebnet.it>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>

On Friday, June 27, 2014 at 1:24 AM, dott.Piergiorgio d' Errico wrote:
> Il 27/06/2014 03:09, Henry Bent ha scritto:
> > I had success booting the Unix Archive's floppy distribution of Ultrix 
> > 1.0 on the MicroVAX 1 simulator.  It appears that the distribution 
> > there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and 
> > will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, 
> > and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To 
> > boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on 
> > RQ2.  The install goes cleanly, albeit with quite a bit of disk 
> > swapping - the installation disk set is 13 floppies.
> >
> > The QVSS is supported and will display some output on boot.  I haven't 
> > yet looked into what is needed to use it as the console (if that's possible?).
> >
> > The kernel seems to support what I assume is the DEQNA - it has 
> > references to a qe device - but I can't figure out how to get it recognized.
> > Unfortunately there are no kernel config files in the distribution, so 
> > I have no idea if the stock kernel is expecting the controller at a 
> > non-standard address.  Any help with this would be greatly 
> > appreciated,
>
> After some misgivings, it actually works here !
>
> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)

Can you elaborate on the 'misgivings' or can you describe what 'works'?

Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip

Thanks.

- Mark



From david.hittner at ngc.com  Fri Jun 27 11:43:32 2014
From: david.hittner at ngc.com (Hittner, David T (IS))
Date: Fri, 27 Jun 2014 15:43:32 +0000
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
Message-ID: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>

AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in SIMH, unless someone has done it recently.
QVSS mono graphics and QDSS color graphics were supported on the MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690) series.
You’d have to map the graphics output to some fairly common graphics renderer for portability: X or QT are probably the best bets. X would be more universally available.

One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows, and I don’t think it was ever back-ported into the SIMH code base. It was based on an older SIMH 2.x release, I think.

I took a stab at writing the QDSS simulator using X once, but couldn’t find enough documentation to figure out what the QDSS card was doing. There’s a lot of weird pixel mapping going on.
I still have real QDSS boards in an  VAX 4000/500 to compare behavior with if anyone ever finds enough QDSS documentation for me.

--

Regarding the DEQNA – there were some early DEQNA boards that had less bits defined in the registers. It’s possible that Ultrix 1.0 sees the ‘wrong’ register state - undefined bits shouldn’t be tested and verified, but in practice, most OS’s *assume* that the undefined bits will be in a specific state at specific times, and will exit if the undefined bits aren’t in the ‘correct’ state.

Dave

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 9:09 PM
To: simh at trailing-edge.com
Subject: EXT :[Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/9cef9fad/attachment-0002.html>

From aek at bitsavers.org  Fri Jun 27 11:53:51 2014
From: aek at bitsavers.org (Al Kossow)
Date: Fri, 27 Jun 2014 08:53:51 -0700
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <53AD938F.3090802@bitsavers.org>

On 6/27/14 8:43 AM, Hittner, David T (IS) wrote:

> One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows

There has been a lot of work on the Rainbow in the past year in MESS.





From Mark at infocomm.com  Fri Jun 27 12:04:23 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 09:04:23 -0700
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2D@REDROOF2.alohasunset.com>

QVSS support was done by Matt Burke (as part of the extra VAX models he implemented) and has been in the MicroVAX I and MicroVAX II simulators available on github for at least a year.

The video support provided uses the video, keyboard and mouse capabilities provided by libSDL.

Since we’ve only got the mono graphics of the QVSS video to worry about now the necessary interfaces to provide color capabilities haven’t been fully worked out, but should be not too hard to work out when necessary.

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Hittner, David T (IS)
Sent: Friday, June 27, 2014 8:44 AM
To: Henry Bent
Cc: simh at trailing-edge.com
Subject: Re: [Simh] EXT : Ultrix 1.0

AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in SIMH, unless someone has done it recently.
QVSS mono graphics and QDSS color graphics were supported on the MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690) series.
You’d have to map the graphics output to some fairly common graphics renderer for portability: X or QT are probably the best bets. X would be more universally available.

One of the 1-off simulators posted on the web really did simulate Rainbow or Pro350 graphics, but it only worked on windows, and I don’t think it was ever back-ported into the SIMH code base. It was based on an older SIMH 2.x release, I think.

I took a stab at writing the QDSS simulator using X once, but couldn’t find enough documentation to figure out what the QDSS card was doing. There’s a lot of weird pixel mapping going on.
I still have real QDSS boards in an  VAX 4000/500 to compare behavior with if anyone ever finds enough QDSS documentation for me.

--

Regarding the DEQNA – there were some early DEQNA boards that had less bits defined in the registers. It’s possible that Ultrix 1.0 sees the ‘wrong’ register state - undefined bits shouldn’t be tested and verified, but in practice, most OS’s *assume* that the undefined bits will be in a specific state at specific times, and will exit if the undefined bits aren’t in the ‘correct’ state.

Dave

From: simh-bounces at trailing-edge.com<mailto:simh-bounces at trailing-edge.com> [mailto:simh-bounces at trailing-edge.com] On Behalf Of Henry Bent
Sent: Thursday, June 26, 2014 9:09 PM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: EXT :[Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/10351cd0/attachment-0002.html>

From tfmorris at gmail.com  Fri Jun 27 12:12:14 2014
From: tfmorris at gmail.com (Tom Morris)
Date: Fri, 27 Jun 2014 12:12:14 -0400
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
Message-ID: <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>

The QVSS was a dumb frame buffer and would be pretty easy to emulate, but
the QDSS used the Dragon "accelerator" chip (or the "drag on" chip as it
was known at the time for its engineering schedule). Emulating the Dragon
behavior would likely be a lot more involved.

Tom


On Fri, Jun 27, 2014 at 11:43 AM, Hittner, David T (IS) <
david.hittner at ngc.com> wrote:

>  AFAIK, the Q-Bus QVSS graphic video card(s) have not been simulated in
> SIMH, unless someone has done it recently.
>
> QVSS mono graphics and QDSS color graphics were supported on the MicroVAX
> 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and VAX 4000 (KA670/690)
> series.
>
> You’d have to map the graphics output to some fairly common graphics
> renderer for portability: X or QT are probably the best bets. X would be
> more universally available.
>
>
>
> One of the 1-off simulators posted on the web really did simulate Rainbow
> or Pro350 graphics, but it only worked on windows, and I don’t think it was
> ever back-ported into the SIMH code base. It was based on an older SIMH 2.x
> release, I think.
>
>
>
> I took a stab at writing the QDSS simulator using X once, but couldn’t
> find enough documentation to figure out what the QDSS card was doing.
> There’s a lot of weird pixel mapping going on.
>
> I still have real QDSS boards in an  VAX 4000/500 to compare behavior with
> if anyone ever finds enough QDSS documentation for me.
>
>
>
> --
>
>
>
> Regarding the DEQNA – there were some early DEQNA boards that had less
> bits defined in the registers. It’s possible that Ultrix 1.0 sees the
> ‘wrong’ register state - undefined bits shouldn’t be tested and verified,
> but in practice, most OS’s **assume** that the undefined bits will be in
> a specific state at specific times, and will exit if the undefined bits
> aren’t in the ‘correct’ state.
>
>
>
> Dave
>
>
>
> *From:* simh-bounces at trailing-edge.com [mailto:
> simh-bounces at trailing-edge.com] *On Behalf Of *Henry Bent
> *Sent:* Thursday, June 26, 2014 9:09 PM
> *To:* simh at trailing-edge.com
> *Subject:* EXT :[Simh] Ultrix 1.0
>
>
>
> I had success booting the Unix Archive's floppy distribution of Ultrix 1.0
> on the MicroVAX 1 simulator.  It appears that the distribution there was
> only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot
> on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2
> need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer,
> put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes
> cleanly, albeit with quite a bit of disk swapping - the installation disk
> set is 13 floppies.
>
> The QVSS is supported and will display some output on boot.  I haven't yet
> looked into what is needed to use it as the console (if that's possible?).
>
> The kernel seems to support what I assume is the DEQNA - it has references
> to a qe device - but I can't figure out how to get it recognized.
> Unfortunately there are no kernel config files in the distribution, so I
> have no idea if the stock kernel is expecting the controller at a
> non-standard address.  Any help with this would be greatly appreciated,
>
> -Henry
>
> _______________________________________________
> 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/20140627/f3746fe1/attachment-0002.html>

From hoelscher-kirchbrak at freenet.de  Fri Jun 27 16:16:19 2014
From: hoelscher-kirchbrak at freenet.de (=?UTF-8?B?SGFucy1VbHJpY2ggSMO2bHNjaGVy?=)
Date: Fri, 27 Jun 2014 22:16:19 +0200
Subject: [Simh] Ultrix 1.0
Message-ID: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>

Henry,
I tried to reproduce your installation using your instructions, but I failed:

sim> b rq1
Loading boot code from ka610.bin
 2..1..0.
Boot
: ra(1,0)vmunix
186016+46652+44656 start 0x10bc
Ultrix-32m V1.0 System #1: Fri Aug 17 11:57:07 EDT 1984
real mem  = 4190208
avail mem = 3374080
using 110 buffers containing 418816 bytes of memory
MicroVAX 1, microcode level = 5
Q22 bus
rqd0 at bus0 csr 172150 vec 774, ipl 17
ra0 at rqd0 slave 0
ra1 at rqd0 slave 1
ra2 at rqd0 slave 2
dz0 at bus0 csr 160100 vec 300, ipl 17
dz1 at bus0 csr 160110 vec 310, ipl 17
trap type 9, code = 800a755c, pc = 80014ba7
panic: Protection fault
syncing disks... done
dumping to dev 901, offset 0
dump succeededLoading boot code from ka610.bin
Rebooting...
 2..1..0.
Boot
: ra(1,0)vmunix

Could you please give me your ini file just in case I missed something there?

Thanks!

P.S.
Your RD52 Image runs fine.
I have a real MicroVAX I, but unfortunately no RD52 :-((
By the way - I'm from Germany, too ...




---
Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen




From hbent at oberlin.edu  Fri Jun 27 16:27:01 2014
From: hbent at oberlin.edu (Henry Bent)
Date: Fri, 27 Jun 2014 16:27:01 -0400
Subject: [Simh] Ultrix 1.0
In-Reply-To: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
References: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
Message-ID: <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>

I don't have an ini file, I just save the state when I'm done and restore
it the next time.  I'm using the latest version from git, if that matters:

MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: f961a98b

I disabled everything I didn't need.  So I guess an ini file would be
something along the lines of:
set cpu idle=ultrixold
set tti 7b
set tto 7b
set cr disabled
set lpt disabled
set rl disabled
set rq0 rd52
set rq1 rx50
set rq2 rx50
set rq3 disabled
set ts disabled
set tq disabled
set xq type=deqna

-Henry




On 27 June 2014 16:16, Hans-Ulrich Hölscher <hoelscher-kirchbrak at freenet.de>
wrote:

> Henry,
> I tried to reproduce your installation using your instructions, but I
> failed:
>
> sim> b rq1
> Loading boot code from ka610.bin
>  2..1..0.
> Boot
> : ra(1,0)vmunix
> 186016+46652+44656 start 0x10bc
> Ultrix-32m V1.0 System #1: Fri Aug 17 11:57:07 EDT 1984
> real mem  = 4190208
> avail mem = 3374080
> using 110 buffers containing 418816 bytes of memory
> MicroVAX 1, microcode level = 5
> Q22 bus
> rqd0 at bus0 csr 172150 vec 774, ipl 17
> ra0 at rqd0 slave 0
> ra1 at rqd0 slave 1
> ra2 at rqd0 slave 2
> dz0 at bus0 csr 160100 vec 300, ipl 17
> dz1 at bus0 csr 160110 vec 310, ipl 17
> trap type 9, code = 800a755c, pc = 80014ba7
> panic: Protection fault
> syncing disks... done
> dumping to dev 901, offset 0
> dump succeededLoading boot code from ka610.bin
> Rebooting...
>  2..1..0.
> Boot
> : ra(1,0)vmunix
>
> Could you please give me your ini file just in case I missed something
> there?
>
> Thanks!
>
> P.S.
> Your RD52 Image runs fine.
> I have a real MicroVAX I, but unfortunately no RD52 :-((
> By the way - I'm from Germany, too ...
>
>
>
>
> ---
> Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen!
> http://email.freenet.de/basic/Informationen
>
>
> _______________________________________________
> 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/20140627/9bedf1c7/attachment-0002.html>

From Mark at infocomm.com  Fri Jun 27 22:54:22 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Fri, 27 Jun 2014 19:54:22 -0700
Subject: [Simh] Ultrix 1.0
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>
References: <0F0B9BFC06289346B88512B91E55670D2F42@EXCHANGE>
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8014DA59283@REDROOF2.alohasunset.com>

Hi Jason,

This is interesting.

The 4.2 and 4.3BSD (and Ultrix) drivers MUST have worked with real hardware, so the best course of action here would be to fix the simulation to match what the software expects.

The code you're pointing at below (if_de.c) is the driver for the DEUNA/DELUA not the DEQNA which the original poster is using.

I could believe that there are issues with the DEUNA implementation for earlier Ultrix and BSD versions.  I'm glad to fix that also if the simulated hardware isn't consistent with how real hardware worked...

Can you remember or better yet, provide a specific case which needs the driver patch you suggest below...

Thanks.


-          Mark

From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Jason Stevens
Sent: Thursday, June 26, 2014 7:35 PM
To: 'Henry Bent'; simh at trailing-edge.com
Subject: Re: [Simh] Ultrix 1.0

I wonder if it's related to the BSD driver for the network card.... Years ago I was playing with 4.2 and 4.3BSD and I never could get the network card to work, so I started to play with the driver, and I found this:

In the  if_de.c driver there is some error checking, that always seems to come back with errors.

------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
/*
 * Ethernet interface receiver interface.
 * If input error just drop packet.
 * Otherwise purge input buffered data path and examine
 * packet to determine type.  If can't determine length
 * from type, then have to drop packet.  Othewise decapsulate
 * packet based on type and pass to type specific higher-level
 * input routine.
 */
derecv(unit)
        int unit;
{
        register struct de_softc *ds = &de_softc[unit];
        register struct de_ring *rp;
        int len;

        rp = &ds->ds_rrent[ds->ds_rindex];
        while ((rp->r_flags & RFLG_OWN) == 0) {
                ds->ds_if.if_ipackets++;
                if (ds->ds_deuba.iff_flags & UBA_NEEDBDP)
                        UBAPURGE(ds->ds_deuba.iff_uba,
                        ds->ds_ifr[ds->ds_rindex].ifrw_bdp);
                len = (rp->r_lenerr&RERR_MLEN) - sizeof (struct ether_header)
                        - 4;    /* don't forget checksum! */
                /* check for errors */
               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
                    (rp->r_flags&(RFLG_STP|RFLG_ENP)) != (RFLG_STP|RFLG_ENP) ||
                    (rp->r_lenerr & (RERR_BUFL|RERR_UBTO|RERR_NCHN)) ||
                    len < ETHERMIN || len > ETHERMTU) {
                        ds->ds_if.if_ierrors++;
                        if (dedebug)
                        printf("de%d: ierror, flags=%b lenerr=%b (len=%d)\n",
                                unit, rp->r_flags, RFLG_BITS, rp->r_lenerr,
                                RERR_BITS, len);
                } else
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
if_dereg.h:#define      RFLG_ERRS       0x40            /* Error summary */
if_dereg.h:#define      RFLG_FRAM       0x20            /* Framing error */
if_dereg.h:#define      RFLG_OFLO       0x10            /* Message overflow */
if_dereg.h:#define      RFLG_CRC        0x08            /* CRC error */
if_dereg.h:#define      RFLG_STP        0x02            /* Start of packet */
if_dereg.h:#define      RFLG_ENP        0x01            /* End of packet */
if_dereg.h:#define      RERR_BUFL       0x8000          /* Buffer length error *
if_dereg.h:#define      RERR_UBTO       0x4000          /* UNIBUS tiemout */
if_dereg.h:#define      RERR_NCHN       0x2000          /* No data chaining */


Now I don't know if Ultrix still has the driver source code... but this was a quick enough fix for me.  And I recall if_de.c being the same from 4.2BSD into 4.3BSD as it was the same fix I used to get them all working on SIMH.




The patch was something like this...
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<
500c500
<               if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
---
> /***          if ((rp->r_flags & (RFLG_ERRS|RFLG_FRAM|RFLG_OFLO|RFLG_CRC)) ||
503a504,505
>                       ***/
>                       if(1==5){
------8<------8<------8<------8<------8<------8<------8<------8<------8<------8<

________________________________
From: Henry Bent [mailto:hbent at oberlin.edu]
Sent: Friday, June 27, 2014 9:09 AM
To: simh at trailing-edge.com<mailto:simh at trailing-edge.com>
Subject: [Simh] Ultrix 1.0

I had success booting the Unix Archive's floppy distribution of Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the distribution there was only meant for a dual-RX50 MicroVAX 1 with an RD drive, and will not boot on any other machine.  RQ0 needs to be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit with quite a bit of disk swapping - the installation disk set is 13 floppies.
The QVSS is supported and will display some output on boot.  I haven't yet looked into what is needed to use it as the console (if that's possible?).

The kernel seems to support what I assume is the DEQNA - it has references to a qe device - but I can't figure out how to get it recognized.  Unfortunately there are no kernel config files in the distribution, so I have no idea if the stock kernel is expecting the controller at a non-standard address.  Any help with this would be greatly appreciated,
-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140627/eeb46e1e/attachment-0002.html>

From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:25:00 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:25:00 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <53AD2A22.7070609@fastwebnet.it>
 <03006E3FC39B5A48AB9DBCCC101090A8013A62AC2B@REDROOF2.alohasunset.com>
Message-ID: <53AE7BDC.2030407@fastwebnet.it>

Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:

>> After some misgivings, it actually works here !
>>
>> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)
>
> Can you elaborate on the 'misgivings' or can you describe what 'works'?

my mistakes in configuring from the printout of sh con given by Henry 
Bent...


> Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip

Either I can't have figured how to set some params, or perhaps was 
implemented but not settable back then; in particular, I can't set, or 
don't get how to set "vector=HHH" but ULTRIX booted and I can do simple 
quick testing with "no vector" in the configuration (ls, cat |more and 
like, I live in southern Italy, and the overheating of actual hardware 
IS an issue for me; if you want that I do more specific looking in 
depth, I'll try to do this during the night....)

Best regards from Italy,
dott. Piergiorgio.



From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:29:56 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:29:56 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>
References: <24c9bbd7311c47163d27d861dac18d36@email.freenet.de>
 <CAKJ3OjmdP5-DDOJmv_qO0v-j=OG3r_3rDUAkEpsp7r7DqZo7jA@mail.gmail.com>
Message-ID: <53AE7D04.80500@fastwebnet.it>

Il 27/06/2014 22:27, Henry Bent ha scritto:
> I don't have an ini file, I just save the state when I'm done and restore
> it the next time.  I'm using the latest version from git, if that matters:
>
> MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: f961a98b
>
> I disabled everything I didn't need.  So I guess an ini file would be
> something along the lines of:
> set cpu idle=ultrixold
> set tti 7b
> set tto 7b
> set cr disabled
> set lpt disabled
> set rl disabled
> set rq0 rd52
> set rq1 rx50
> set rq2 rx50
> set rq3 disabled
> set ts disabled
> set tq disabled
> set xq type=deqna

I fully confirm this, it is how I have booted ultrix on a 1 yrs ago old 
build of SIMH 4 beta....

Best regards from Italy,
dott. Piergiorgio.




From Mark at infocomm.com  Sat Jun 28 04:37:27 2014
From: Mark at infocomm.com (Mark Pizzolato - Info Comm)
Date: Sat, 28 Jun 2014 01:37:27 -0700
Subject: [Simh] Ultrix 1.0
Message-ID: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>


On Jun 28, 2014 1:25 AM, "dott.Piergiorgio d' Errico" <dott.piergiorgio at fastwebnet.it> wrote:
>
> Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:
>
> >> After some misgivings, it actually works here !
> >>
> >> (my build is: MicroVAX I (KA610) simulator V4.0-0 Beta        git commit id: 796cbd27)
> >
> > Can you elaborate on the 'misgivings' or can you describe what 'works'?
>
> my mistakes in configuring from the printout of sh con given by Henry
> Bent...

So, what you mean is that you can boot Henry's disk in the simulator, not that when you boot it networking 'works'.  Right??

> > Git commit id is from back in November 2013.  Can you confirm that what you believe worked with that version also works with the latest codebase at https://github.com/simh/simh/archive/master.zip
>
> Either I can't have figured how to set some params, or perhaps was
> implemented but not settable back then; in particular, I can't set, or
> don't get how to set "vector=HHH" but ULTRIX booted and I can do simple
> quick testing with "no vector" in the configuration (ls, cat |more and
> like, I live in southern Italy, and the overheating of actual hardware
> IS an issue for me; if you want that I do more specific looking in
> depth, I'll try to do this during the night....)

The DEQNA device does not have a vector set by switches.  The vector is set programmatically by the device driver.  This is also true for the RQ (MSCP) and TQ (TMSCP) devices as well.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140628/cd0b0753/attachment-0002.html>

From dott.piergiorgio at fastwebnet.it  Sat Jun 28 04:52:31 2014
From: dott.piergiorgio at fastwebnet.it (dott.Piergiorgio d' Errico)
Date: Sat, 28 Jun 2014 10:52:31 +0200
Subject: [Simh] Ultrix 1.0
In-Reply-To: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>
References: <03006E3FC39B5A48AB9DBCCC101090A8014DA61A5D@REDROOF2.alohasunset.com>
Message-ID: <53AE824F.4050309@fastwebnet.it>

Il 28/06/2014 10:37, Mark Pizzolato - Info Comm ha scritto:
> So, what you mean is that you can boot Henry's disk in the simulator, not that when you boot it networking 'works'.  Right??

no, that I initially don't get right how to convert the sh con output 
into actual simh commands... pls notice that when I wrote "misgivings" I 
always refer to human erring, not machine errors....

Best regards from Italy,
dott. Piergiorgio.



From matt at 9track.net  Sat Jun 28 19:52:16 2014
From: matt at 9track.net (Matt Burke)
Date: Sun, 29 Jun 2014 00:52:16 +0100
Subject: [Simh] EXT : Ultrix 1.0
In-Reply-To: <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>
References: <CAKJ3OjnR3sGBv5Hny4-VW53HUv0vwZp-g6XdqQgSyu+TKq7jkg@mail.gmail.com>
 <9C9FDA2BCCFB5E4098DEB87AC47B94503E32CE25@XMBVAG73.northgrum.com>
 <CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com>
Message-ID: <53AF5530.8030608@9track.net>

That's right, the QVSS wasn't too bad to implement once I worked out how
to handle the scan-line map and the cursor overlay.

I've partly implemented the QDSS, but it's very complicated. The host
does not have direct access to the frame buffer as with the QVSS. There
is an "Adder" address processor that handles the movement of data
between the QBus and the frame buffer. The "Adder" also transfers
commands or "rasterops" to the 4 or 8 "Viper" video processors, each of
which manipulate 1 plane of data in the frame buffer. Each plane can be
individually stretched, skewed, rotated etc. by these processors.

There's enough documentation available to do this, but given the
complexity I don't think it will get finished any time soon. You can see
some of the progress with Simh video here:

http://9track.net/simh/video/

Matt

On 27/06/2014 17:12, Tom Morris wrote:
> The QVSS was a dumb frame buffer and would be pretty easy to emulate,
> but the QDSS used the Dragon "accelerator" chip (or the "drag on" chip
> as it was known at the time for its engineering schedule). Emulating
> the Dragon behavior would likely be a lot more involved.
>
> Tom
>
>
> On Fri, Jun 27, 2014 at 11:43 AM, Hittner, David T (IS)
> <david.hittner at ngc.com <mailto:david.hittner at ngc.com>> wrote:
>
>     AFAIK, the Q-Bus QVSS graphic video card(s) have not been
>     simulated in SIMH, unless someone has done it recently.
>
>     QVSS mono graphics and QDSS color graphics were supported on the
>     MicroVAX 1 (KA610), MicroVAX 2 (KA630), MicroVAX 3 (KA65x), and
>     VAX 4000 (KA670/690) series.
>
>     You'd have to map the graphics output to some fairly common
>     graphics renderer for portability: X or QT are probably the best
>     bets. X would be more universally available.
>
>      
>
>     One of the 1-off simulators posted on the web really did simulate
>     Rainbow or Pro350 graphics, but it only worked on windows, and I
>     don't think it was ever back-ported into the SIMH code base. It
>     was based on an older SIMH 2.x release, I think.
>
>      
>
>     I took a stab at writing the QDSS simulator using X once, but
>     couldn't find enough documentation to figure out what the QDSS
>     card was doing. There's a lot of weird pixel mapping going on.
>
>     I still have real QDSS boards in an  VAX 4000/500 to compare
>     behavior with if anyone ever finds enough QDSS documentation for me.
>
>      
>
>     --
>
>      
>
>     Regarding the DEQNA -- there were some early DEQNA boards that had
>     less bits defined in the registers. It's possible that Ultrix 1.0
>     sees the 'wrong' register state - undefined bits shouldn't be
>     tested and verified, but in practice, most OS's **assume** that
>     the undefined bits will be in a specific state at specific times,
>     and will exit if the undefined bits aren't in the 'correct' state.
>
>      
>
>     Dave
>
>      
>
>     *From:*simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>
>     [mailto:simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>] *On Behalf Of *Henry Bent
>     *Sent:* Thursday, June 26, 2014 9:09 PM
>     *To:* simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>     *Subject:* EXT :[Simh] Ultrix 1.0
>
>      
>
>     I had success booting the Unix Archive's floppy distribution of
>     Ultrix 1.0 on the MicroVAX 1 simulator.  It appears that the
>     distribution there was only meant for a dual-RX50 MicroVAX 1 with
>     an RD drive, and will not boot on any other machine.  RQ0 needs to
>     be an RD51 or RD52, and RQ1 and RQ2 need to be RX50s.  TTI and TTO
>     need to be 7 bit.  To boot the installer, put 32m-1.0-bin/01 on
>     RQ1 and 32m-1.0-bin/02 on RQ2.  The install goes cleanly, albeit
>     with quite a bit of disk swapping - the installation disk set is
>     13 floppies.
>
>     The QVSS is supported and will display some output on boot.  I
>     haven't yet looked into what is needed to use it as the console
>     (if that's possible?).
>
>     The kernel seems to support what I assume is the DEQNA - it has
>     references to a qe device - but I can't figure out how to get it
>     recognized.  Unfortunately there are no kernel config files in the
>     distribution, so I have no idea if the stock kernel is expecting
>     the controller at a non-standard address.  Any help with this
>     would be greatly appreciated,
>
>     -Henry
>
>
>     _______________________________________________
>     Simh mailing list
>     Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>     http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
>
>
> _______________________________________________
> 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/20140629/de990924/attachment-0002.html>

From b4 at gewt.net  Sun Jun 29 07:11:51 2014
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 29 Jun 2014 07:11:51 -0400 (Eastern Daylight Time)
Subject: [Simh] PCL-11?
Message-ID: <alpine.WNT.2.01.1406290709160.3040@melanie.gimme-sympathy.org>

Hello,

Does anyone know anything about the PCL-11 communications stuff and have 
any plans to implement it?  I can't find too much about it in a quick 
20-second look, others will likely fare better.

Also: 32V, 3BSD, and System III do not boot in SIMH 3.9 and above.  They 
boot fine in 3.8-1, however.  They throw a kernel trap.  I can't share the 
SysIII obviously...but I can boot any changes for testing.  3BSD and 32V 
will likely be the same.

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From frisbie at flying-disk.com  Sun Jun 29 12:32:58 2014
From: frisbie at flying-disk.com (Alan Frisbie)
Date: Sun, 29 Jun 2014 09:32:58 -0700 (PDT)
Subject: [Simh] PCL-11?
Message-ID: <14062909325846_448@slug.flying-disk.com>


> Does anyone know anything about the PCL-11 communications stuff
> and have any plans to implement it?  I can't find too much about
> it in a quick 20-second look, others will likely fare better.

I used it on both PDP-11/44 (RSX-11M+) and VAX/780 (VMS) systems
back in the early 1980s.   I even had to work on the VMS device
driver so that DECnet would work.

Unfortunately, I don't have any of the documentation or code from
those projects.   Just the memory that Field Service had a
terrible time adjusting the PCL bus timing so that they would
work.   Those wide cables were not pleasant to work with.

If you have any specific questions, it might jog some dusty bits
loose in my mind.

Alan Frisbie


From gltmailbox-simh at yahoo.com  Sun Jun 29 22:14:38 2014
From: gltmailbox-simh at yahoo.com (Galen Tackett)
Date: Sun, 29 Jun 2014 22:14:38 -0400
Subject: [Simh] PCL-11?
In-Reply-To: <14062909325846_448@slug.flying-disk.com>
References: <14062909325846_448@slug.flying-disk.com>
Message-ID: <29022CB1-C4BE-4778-BD45-71BB6B69CB52@yahoo.com>


> 
>> Does anyone know anything about the PCL-11 communications stuff
>> and have any plans to implement it?  I can't find too much about
>> it in a quick 20-second look, others will likely fare better.
> 
> I used it on both PDP-11/44 (RSX-11M+) and VAX/780 (VMS) systems
> back in the early 1980s.   I even had to work on the VMS device
> driver so that DECnet would work.
> 
What was the PCL-11? I’m trying to remember if I ever encountered one. (I wouldn’t have anything helpful to offer, I’m afraid—just reminiscing.)

One device I spent a lot of time with, my first year out of college, was the DA-11B, a memory to memory DMA link which we used at Lockheed between several LSI-11 data collection stations running RSX-11S and a PDP-11/60 with RSX-11M that ran a static load test system for us. There were no device drivers for it, or at least none suitable for this purpose, so I wrote the link software we used—partly in Macro-11, of course, but also partly using DECUS C.

A coworker of mine had found a way to use the Connect to Interrupt Vector directive (CINT$) with a program that was mostly in FORTRAN, using some linkage code in Macro. I turned this into something similar for use with DECUS C.

We used a differential-signal version of the DA-11 (maybe that’s what the -B was for?) to go the relatively long distance (for DMA, in those days) from four locations on our big 7 story test stand, into the small computer room located off the 2nd or 4th floor--I forget which for certain, but our office was a room two stories up from that.

As I recall, our DEC Field Service rep. had a bit of work to do, to get this hardware working reliably. There may have been problems involving the flat, wide-ish cables that before installation had been pre-pulled through the trays on the test stand. Perhaps grounding issues?

That was a fun project and a nice challenge right out of college. I constantly had my hands on/in both hardware and software. Ah, the memories...