[Simh] EXT : Ultrix 1.0

[Matt Burke]

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.

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.

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:

http://9track.net/simh/video/

Matt

On 27/06/2014 17:12, Tom Morris wrote:
> 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.
>
> Tom
>
>
> On Fri, Jun 27, 2014 at 11:43 AM, Hittner, David T (IS)
> <david.hittner at ngc.com <mailto:david.hittner at ngc.com>> wrote:
>
>     AFAIK, the Q-Bus QVSS graphic video card(s) have not been
>     simulated in SIMH, unless someone has done it recently.
>
>     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.
>
>     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.
>
>      
>
>     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.
>
>      
>
>     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.
>
>     I still have real QDSS boards in an  VAX 4000/500 to compare
>     behavior with if anyone ever finds enough QDSS documentation for me.
>
>      
>
>     --
>
>      
>
>     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 **assume** 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.
>
>      
>
>     Dave
>
>      
>
>     *From:*simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>
>     [mailto:simh-bounces at trailing-edge.com
>     <mailto:simh-bounces at trailing-edge.com>] *On Behalf Of *Henry Bent
>     *Sent:* Thursday, June 26, 2014 9:09 PM
>     *To:* simh at trailing-edge.com <mailto:simh at trailing-edge.com>
>     *Subject:* EXT :[Simh] Ultrix 1.0
>
>      
>
>     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.
>
>     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?).
>
>     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,
>
>     -Henry
>
>
>     _______________________________________________
>     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
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20140629/de990924/attachment-0002.html>