[Simh] Ultrix 4.0 and DEQNA-LOCK

Mark Pizzolato Mark at infocomm.com
Wed Aug 31 13:14:09 EDT 2016


On Wednesday, August 31, 2016 at 8:36 AM, Johnny Billquist wrote:
> Well, there certainly is a bit more information about what DEQNA-LOCK mode
> implies in the manual... Some bits and behaviors on the Vector Address
> Register are working differently in DEQNA-LOCK mode. Also, if you set
> DEQNA-Lock mode, SW4 have a different meaning that if S3 is off.
> It affects how/if remote booting is enabled, or if a=sanity timers are enabled.
> A lot of the stuff around this have to do with MOP things, self tests and sanity
> timers. Not sure how much of that would be interesting to implement in
> simh... And while maybe there aren't enough details for an actual
> implementation, the manual for the DELQA have a whole section of what that
> switch controls...

I didn't say that there wasn't info there, but most of that is pure setup stuff and specifically unrelated to actually operating the board to send and/or receive packets.  Much/most/all of what is described is implemented, possibly not correctly, without precise examples of how it is used.

This lock mode stuff may be unrelated to the segfault that was mentioned which I'll be glad to explore if someone can provide details I can see directly.

> All that said, based on documentation and Ragges post of the Ultrix sources, it
> would appear that Ultrix correctly identifies this as a DELQA board, but it
> thinks that SW3 is set (DEQNA-LOCK).

As I vaguely recall, I think it was possible, or ambiguously defined that lock mode could also be set programmatically.

- Mark

> Cory, could you post the output from showing the device in simh?
> I wonder if there might be some confusion about how to turn off lock mode.
> I've never even tried modifying that. By default, I would assume it would be
> correctly configured, meaning it should work right if you don't try to "fix it".
> 
> I haven't actually looked in the simh code, but might do that later if this is still
> ongoing. :-)
> 
> 	Johnny
> 
> On 2016-08-31 17:06, Mark Pizzolato wrote:
> > The pdp11_xq device simulates 3 boards:
> >
> > 1)      DEQNA
> >
> > 2)      DELQA
> >
> > 3)      DELQA-T
> >
> >
> >
> > The DELQA documentation refers to specifically enabling DEQNA Lock
> > mode which can be specified by switch and/or programmatically.
> >
> >
> >
> > When implementing the simulator, beyond the fact that there is a DEQNA
> > Lock mode, the document really doesn’t mention what is
> > special/different about the behavior of the DELQA device when it is in
> DEQNA Lock mode.
> > VMS doesn’t handle the DEQNA and the DELQA differently beyond merely
> > identifying one board from another.  VMS does detect the DELQA-T and
> > it leverages the completely different/more efficient/less ambiguous
> > programming model.
> >
> >
> >
> > If someone can provide the various versions of the Ultrix drivers for
> > this device and maybe explain how the different devices are treated
> > differently by those drivers we can make the simulated devices more
> > precisely match what the original hardware did.
> >
> >
> >
> > *From:*Simh [mailto:simh-bounces at trailing-edge.com] *On Behalf Of
> > *Cory Smelosky
> > *Sent:* Wednesday, August 31, 2016 7:52 AM
> > *To:* Johnny Billquist <bqt at softjar.se>
> > *Cc:* simh at trailing-edge.com
> > *Subject:* Re: [Simh] Ultrix 4.0 and DEQNA-LOCK
> >
> >
> >
> > [inline]
> >
> >
> > Sent from my iPhone
> >
> >
> > On Aug 31, 2016, at 03:30, Johnny Billquist <bqt at softjar.se
> > <mailto:bqt at softjar.se>> wrote:
> >
> >     Hi.
> >
> >     On 2016-08-31 04:43, Cory Smelosky wrote:
> >
> >         4.5 exhibits the same "now it's suddenly in DEQNA" mode behaviour.
> >
> >
> >     Well, then I retract my guess. By 4.5 I would expect the code to
> >     handle a DELQA natively. Ragge also posted the source code for 4.5,
> >     which clearly states that it should handle the DELQA...
> >
> >
> >
> > Yeah - I'm very confused by that!
> >
> >
> >
> >
> >
> >         (it also panic()s every first boot after first starting the
> >         emulator)
> >
> >
> >     Huh. That really do sound like a bug. Since it don't happen on real
> >     hardware I would guess a simh issue. What kind of VAX are you
> >     emulating, by the way? The 3900?
> >
> >
> >
> > Yup - 3900. It didn't occur to me until now it might not be
> > coincidence it panics with a segfault right after probing the network
> > card...I wasn't noticing any network issues until now though I guess.
> >
> >
> >
> >
> >        Johnny
> >
> >
> >
> >
> >         On Tue, Aug 30, 2016, at 08:04, Clem Cole wrote:
> >
> >
> >
> >             On Tue, Aug 30, 2016 at 6:38 AM, Johnny Billquist
> >             <bqt at softjar.se <mailto:bqt at softjar.se>> wrote:
> >
> >                 Not sure there are any bugs here. Ultrix might just
> >                 change it to run in DEQNA mode. Maybe because it didnät
> >                 have a driver for running it in DELQA mode in 4.0? Just
> >                 guessing here, but it don't look to me as if there
> >                 actually is a bug anywhere.
> >
> >
> >
> >             I've long since forgotten the details.    The 4.5 SPD says
> >             it should work (modulo firmware - which I suspect simh is
> >             assuming that).   Johnny is probably right.
> >
> >
> >
> >
> >
> >             Cory: Is there a reason you are running 4.0 not not
> >             something later than 4.4.   There a ton of bugs fixed in the
> >             4.3/4.4 development.  The Vax has sort of been forgotten by
> >             the Ultrix/Tru64 teams in favor of the PMAX and the Alpha;
> >              thus entropy had set in on the Vax code.   Even though 4.3
> >             was not an officially bug release, it had more bug fixes in
> >             that any previous one, because a number of just got sick of
> >             dealing with it and there was a 3-4 week development hiatus
> >             where we just cleaned up things.  IIRC this was particularly
> >             true for the networking stack, because we were heaving
> >             pathworks development then and the Pathworks stack kept
> >             turning up small boundary conditions in the Unix side.
> >
> >
> >
> >             Anyway -- if you are going to run Ultrix, I highly recommend
> >             4.5 - which was really the most stable of the all the Ultrix
> >             releases.  For instance, the SCSI stack is (finally) common
> >             with Tru64, as we back ported Fred's Alpha stack to the Vax
> >             and PMAX.   As a result it will cover a lot more devices.
> >               I seem to remember we did some similar things in the
> >             Network code too, but again I've forgotten (I was worrying
> >             about TruClusters at that time but would occasionally
> >             consult to the Ultrix folks).
> >
> >             _________________________________________________
> >
> >             Simh mailing list
> >
> >             Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
> >
> >             http://mailman.trailing-edge.com/mailman/listinfo/simh
> >
> >             Email had 1 attachment:
> >
> >
> >
> >
> >
> >             * ultrix4.5_spd.pdf
> >
> >              297k (application/pdf)
> >
> >
> >
> >         --
> >
> >          Cory Smelosky
> >
> >          b4 at gewt.net <mailto:b4 at gewt.net>
> >
> >         _______________________________________________
> >
> >         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 <mailto:Simh at trailing-edge.com>
> >     http://mailman.trailing-edge.com/mailman/listinfo/simh
> >



More information about the Simh mailing list