On 2016-08-31 19:14, Mark Pizzolato wrote:
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.
Well, what you said is still in the quote below. But that's beside the
point here.
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.
Agreed. It don't seem likely they are related when I think about it.
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.
It is definitely possible. The manual points out the bit that controls
this, and just says that at reset, the value of the bit is taken from SW3.
But the code Ragge posted shows that at detection time, it probes wether
the device in a DEQNA or a DELQA, and once it decides it is a DELQA, it
examines bit 15 in the vector register to check wether it is in lock
mode, so something has set that bit. On real hardware, it will be
reflected from SW3. I'm thinking/wondering if the command that Cory uses
in simh might not actually set the bit, instead (as he might think), it
is cleared.
Johnny
- 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-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