<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="http://9track.net/simh/video/">http://9track.net/simh/video/</a><br>
<br>
Matt<br>
<br>
On 27/06/2014 17:12, Tom Morris wrote:<br>
</div>
<blockquote
cite="mid:CAE9vqEEbjLn5XNYThFkt9owFyuGX=LtORLF6jwrduDCZzR82Qg@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div>
<br>
</div>
<div>Tom</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Jun 27, 2014 at 11:43 AM,
Hittner, David T (IS) <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:david.hittner@ngc.com"
target="_blank">david.hittner@ngc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">AFAIK,
the Q-Bus QVSS graphic video card(s) have not been
simulated in SIMH, unless someone has done it
recently.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
still have real QDSS boards in an VAX 4000/500 to
compare behavior with if anyone ever finds enough
QDSS documentation for me.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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 *<b>assume</b>*
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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Dave</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div style="border:none;border-top:solid #b5c4df
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:simh-bounces@trailing-edge.com"
target="_blank">simh-bounces@trailing-edge.com</a>
[mailto:<a moz-do-not-send="true"
href="mailto:simh-bounces@trailing-edge.com"
target="_blank">simh-bounces@trailing-edge.com</a>]
<b>On Behalf Of </b>Henry Bent<br>
<b>Sent:</b> Thursday, June 26, 2014 9:09 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:simh@trailing-edge.com"
target="_blank">simh@trailing-edge.com</a><br>
<b>Subject:</b> EXT :[Simh] Ultrix 1.0</span></p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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?).<br>
<br>
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,
</p>
</div>
<p class="MsoNormal">-Henry</p>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Simh mailing list<br>
<a moz-do-not-send="true"
href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a><br>
<a moz-do-not-send="true"
href="http://mailman.trailing-edge.com/mailman/listinfo/simh"
target="_blank">http://mailman.trailing-edge.com/mailman/listinfo/simh</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Simh mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a></pre>
</blockquote>
<br>
</body>
</html>