Re: [Simh] Ultrix 1.0

[dott.Piergiorgio d' Errico]

Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:


After some misgivings, it actually works here !

(my build is: MicroVAX I (KA610) simulator V4.0-0 Betagit commit id: 
796cbd27)


Can you elaborate on the 'misgivings' or can you describe what 'works'?


my mistakes in configuring from the printout of sh con given by Henry 
Bent...




Git commit id is from back in November 2013.  Can you confirm that what you 
believe worked with that version also works with the latest codebase at 
https://github.com/simh/simh/archive/master.zip


Either I can't have figured how to set some params, or perhaps was 
implemented but not settable back then; in particular, I can't set, or 
don't get how to set "vector=HHH" but ULTRIX booted and I can do simple 
quick testing with "no vector" in the configuration (ls, cat |more and 
like, I live in southern Italy, and the overheating of actual hardware 
IS an issue for me; if you want that I do more specific looking in 
depth, I'll try to do this during the night)


Best regards from Italy,
dott. Piergiorgio.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Ultrix 1.0

[dott.Piergiorgio d' Errico]

Il 27/06/2014 22:27, Henry Bent ha scritto:

I don't have an ini file, I just save the state when I'm done and restore
it the next time.  I'm using the latest version from git, if that matters:

MicroVAX I (KA610) simulator V4.0-0 Betagit commit id: f961a98b

I disabled everything I didn't need.  So I guess an ini file would be
something along the lines of:
set cpu idle=ultrixold
set tti 7b
set tto 7b
set cr disabled
set lpt disabled
set rl disabled
set rq0 rd52
set rq1 rx50
set rq2 rx50
set rq3 disabled
set ts disabled
set tq disabled
set xq type=deqna


I fully confirm this, it is how I have booted ultrix on a 1 yrs ago old 
build of SIMH 4 beta


Best regards from Italy,
dott. Piergiorgio.


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Ultrix 1.0

[Mark Pizzolato - Info Comm]

On Jun 28, 2014 1:25 AM, "dott.Piergiorgio d' Errico" 
 wrote:
>
> Il 27/06/2014 13:01, Mark Pizzolato - Info Comm ha scritto:
>
> >> After some misgivings, it actually works here !
> >>
> >> (my build is: MicroVAX I (KA610) simulator V4.0-0 Betagit commit 
> >> id: 796cbd27)
> >
> > Can you elaborate on the 'misgivings' or can you describe what 'works'?
>
> my mistakes in configuring from the printout of sh con given by Henry
> Bent...

So, what you mean is that you can boot Henry's disk in the simulator, not that 
when you boot it networking 'works'.  Right??

> > Git commit id is from back in November 2013.  Can you confirm that what you 
> > believe worked with that version also works with the latest codebase at 
> > https://github.com/simh/simh/archive/master.zip
>
> Either I can't have figured how to set some params, or perhaps was
> implemented but not settable back then; in particular, I can't set, or
> don't get how to set "vector=HHH" but ULTRIX booted and I can do simple
> quick testing with "no vector" in the configuration (ls, cat |more and
> like, I live in southern Italy, and the overheating of actual hardware
> IS an issue for me; if you want that I do more specific looking in
> depth, I'll try to do this during the night)

The DEQNA device does not have a vector set by switches.  The vector is set 
programmatically by the device driver.  This is also true for the RQ (MSCP) and 
TQ (TMSCP) devices as well.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Ultrix 1.0

[dott.Piergiorgio d' Errico]

Il 28/06/2014 10:37, Mark Pizzolato - Info Comm ha scritto:

So, what you mean is that you can boot Henry's disk in the simulator, not that 
when you boot it networking 'works'.  Right??


no, that I initially don't get right how to convert the sh con output 
into actual simh commands... pls notice that when I wrote "misgivings" I 
always refer to human erring, not machine errors


Best regards from Italy,
dott. Piergiorgio.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [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)
> mailto:david.hitt...@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-boun...@trailing-edge.com
> 
> [mailto:simh-boun...@trailing-edge.com
> ] *On Behalf Of *Henry Bent
> *Sent:* Thursday, June 26, 2014 9:09 PM
> *To:* simh@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@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

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh