[Simh] DECwindows issues

[Mark Pizzolato]

Hi Hans,

On Monday, July 16, 2018 at 10:33 AM, Hans Hübner wrote:
> I am trying to use SIMH to run VAX LISP on VMS in graphical mode, 
> which has proven to be kind of challenging and I'm now at a point 
> where I wonder if someone else can help me with some issues 
> (some genuinely SIMH issues, some more in the VMS/DECwindows 
> area).  I'm using FreeBSD 11.2 as host with both SIMH V3.9-0 and 
> V4.0-0 Current git commit id: 097eb7b6.  V4.0-0 is a little unstable 
> so I'm often reverting to V3.9-0 if I don't need the qvss framebuffer.
> 
> I'm using VMS 5.5H2 with this SIMH configuration:
> [...]
>
> Here are the issues that I have;
>
> If I run DECwindows on the qvss frame buffer backed by Xorg, the 
> mouse cursor jumps around erratically.  

This is a known issue on some host platforms.  A fix to this is pending
Integration into the master branch.  When that is done, this should 
work as expected.

> I wonder if this is related to the fact that DECwindows switches the 
> screen resolution of the qvss framebuffer.  When the system initially 
> starts, the black qvss windows only occupies part of the Xorg screen, 
> but when DECwindows starts, it expands the window to the full 
> resolution of the X display.

I haven't seen that.  The QVSS device simulation specifically simulates 
the very basic QVSS framebuffer which is constantly at 1024x864 and 
since that is what the original QVSS was capable of interfacing with, 
there is no provision for dynamically changing those dimensions.

> Often enough, I get a "?53 2 0A FF 00 0000" message in the KA655-B 
> monitor and cannot boot.  I recall that this was mentioned recently 
> in this list.  To me, it happens quite often.

This is a failure in the boot ROM's diagnostics when it tests some 
aspect of the simulated system's timing capabilities.  Since it is timing 
related attempts to track down the subtle case when this happens are 
affected by Heisenberg and don't happen when reasonable information 
is being gathered.  I hope to get a clear failure I can work from some time.

Meanwhile, when you get that error, you can actually boot the system, 
but the ROM won't autoboot.  You should still be able to "BOOT DUA0" 
when at the ">>>" prompt.

> During normal system operation with V4.4-0, the simulator sometimes
>  halts with messages like "Invalid argument, PC: 806EEB6A (MOVL 4(SP),(SP))" 
> or "Invalid argument, PC: 00083C16 (BEQL 83C35)".  If I type "c" at the 
> "sim>" prompt, the system continues to run.  Unfortunately, I could not 
> figure out how to cause this issue. 

I can't yet either.  I don't see this with the current code, but the most 
recent commits (today) in the github/simh/simh master branch will produce
more contextual error messages that should help tracking down the root cause.
Please pick up the latest code and if you see messages like this again, let me
know directly or create an issue at https://github.com/simh/simh/issues

> Starting simh V4.0-0 takes something like three seconds before the iniitial 
> "MicroVAX 3900 simulator V4.0-0 Current        git commit id: 097eb7b6" 
> message is printed.  V3.9-0 starts much faster (not a big deal, just wondering).

This is by design, and is due to attempts to more precisely measure the timing 
parameters of your host system environment.  Like you said, not a big deal.

> Running DECwindows on a remote X Server (Xorg or Xquartz) kind of works, 
> but for some reason, only some of the DEC fonts which I've extracted using 
> getbdf from the VMS X Server are listed in xlsfonts.  In particular, the menu 
> font that VAX LISP uses is missing.

I can't speak to why your local X server might not interpret these fonts, but
there may have been some DEC specific font format details which never made
it back to Xorg.  Hopefully you won't need to deal with at all once you can
use the QVSS to as a display with DEC's X server leveraging its local fonts.

- Mark