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...
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).
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-boun...@trailing-edge.com] *On Behalf Of *Cory
Smelosky
*Sent:* Wednesday, August 31, 2016 7:52 AM
*To:* Johnny Billquist <b...@softjar.se>
*Cc:* simh@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 <b...@softjar.se
<mailto:b...@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
<b...@softjar.se <mailto:b...@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@trailing-edge.com <mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
Email had 1 attachment:
* ultrix4.5_spd.pdf
297k (application/pdf)
--
Cory Smelosky
b...@gewt.net <mailto:b...@gewt.net>
_______________________________________________
Simh mailing list
Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
