Re: [Simh] MAME and simh

[Matt Burke]

On 01/07/2020 14:34, Peter Allan wrote:
>
>  https://wiki.mamedev.org/index.php/MAME_and_SIMH
>
> The latter page looks like it should be just what I am looking for,
> but it describes using a VT240 ROM. My vt240 ROM doesn't work. My
> vt220 ROM does work, but when I follow the instructions to 'press F3
> to enter setup', nothing happens.
>
>

The VT220 emulation within MAME is just a skeleton, there is very little
code behind it. I did some work on it a few years ago (along with the
LK201) and I managed to get it to pass a few self tests but didn't get
to the point of displaying anything on the screen.

You might want to try the VT240 with the ROMs from archive.org:

https://archive.org/download/MAME_0.209_ROMs_merged/MAME_0.209_ROMs_merged.zip/vt240.zip

These should be the ones that were used to develop the emulator.

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

Re: [Simh] vmb.exe - info - source code ? / vax (no O.S.) disk programming

[Matt Burke]

On 12/05/2020 15:23, Mike Stramba wrote:
> What is the "story"  with vmb.exe ?
>
> Is there source code for it ?
>
> If not, why not ?
>
> Is it "abandon ware" ?
>
> I'm interested in seeing how it  does  "raw disk" access.
>
> I have MSCP Basic Disk Functions Manual AA-L619A-TK Version 1.2 and
> EK-UDA50-UG-002_UDA50_Users_Guide_Oct82.pdf
>
> Are there any other relevant docs ?
>

VMB has different drivers that are invoked for each controller type
(MASSBUS, MSCP etc). These drivers are just minimal equivalents of the
full drivers within the operating system. Usually they rely on polling
rather than using interrupts. Other than that there is nothing
particularly special that takes place here.

Other documents to look at are:

http://www.bitsavers.org/pdf/dec/dsa/mscp/Mass_Storage_Control_Protocol_Ver_2.4.0_Jun92.txt

and

http://www.bitsavers.org/pdf/dec/disc/uda50/AA-L621A-TK_UnibusPortDescription_1982.pdf

In particular look at chapter 4 which describes the command and response
rings and chapter 9 which describes the initialisation sequence.

Probably the best way to see VMB in action would be to use the debug
feature within Simh. I would recommend using the VAX-11/780 simulator
for this as VMB is loaded directly after issuing the boot command:

sim> set debug stdout
sim> set rq debug
sim> boot rq0

DBG(5000)> RQ TRACE: rq_reset
DBG(5000)> RQ TRACE: rq_clrint
Loading boot code from internal vmb.exe
DBG(3470473)> RQ TRACE: rq_reset
DBG(3470473)> RQ TRACE: rq_clrint

Writing to the initialisation/polling register resets the controller:

DBG(3483139)> RQ REG: rq_wr(PA=0x2013F468 [IP], access=2, data=0x)
DBG(3483139)> RQ TRACE: rq_reset
DBG(3483139)> RQ TRACE: rq_clrint

Values (as described in chapter 9) are written to the status & address
register in order to complete the 4 step initialisation sequence:

DBG(3483139)> RQ REQ: initialization started
DBG(3486350)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x0940
DBG(3486357)> RQ REG: rq_wr(PA=0x2013F46A [SA], access=2, data=0x8000)
DBG(3486807)> RQ TRACE: rq_quesvc
DBG(3486807)> RQ INIT: CSTA=0, SAW=0x8000
DBG(3489569)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x1080
DBG(3489576)> RQ REG: rq_wr(PA=0x2013F46A [SA], access=2, data=0xDDD8)
DBG(3490026)> RQ TRACE: rq_quesvc
DBG(3490026)> RQ INIT: CSTA=2, SAW=0xDDD8
DBG(3492788)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x2000
DBG(3492795)> RQ REG: rq_wr(PA=0x2013F46A [SA], access=2, data=0x0003)
DBG(3493245)> RQ TRACE: rq_quesvc
DBG(3493245)> RQ INIT: CSTA=3, SAW=0x3
DBG(3496007)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x4063
DBG(3496014)> RQ REG: rq_wr(PA=0x2013F46A [SA], access=2, data=0x0001)
DBG(3496024)> RQ TRACE: rq_quesvc
DBG(3496024)> RQ INIT: CSTA=6, SAW=0x1
DBG(3496024)> RQ REQ: initialization complete

The initialisation/polling register is read to notify the controller
that a new command packet had been placed in the command ring by the host:

DBG(3496029)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x
DBG(3496033)> RQ REG: rq_rd(PA=0x2013F468 [IP], access=0)=0x
DBG(3496033)> RQ REQ: poll started, PC=1076
DBG(3496034)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x

The controller processes a "Set Controller Characteristics" command from
the command ring:

DBG(3496133)> RQ TRACE: rq_quesvc
DBG(3496133)> RQ REQ: cmd=0004(SCC), mod=, unit=0, bc=,
ma=00FF, lbn=
DBG(3496133)> RQ TRACE: rq_mscp - Queue
DBG(3496133)> RQ TRACE: rq_scc

A response packet is placed in the response ring by the controller:

DBG(3496133)> RQ REQ: rsp=0084, sts=

The initialisation/polling register is read again to notify the
controller that a another command packet had been placed in the command
ring by the host:

DBG(3496148)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x
DBG(3496152)> RQ REG: rq_rd(PA=0x2013F468 [IP], access=0)=0x
DBG(3496152)> RQ REQ: poll started, PC=1076
DBG(3496153)> RQ REG: rq_rd(PA=0x2013F46A [SA], access=0)=0x

The controller processes an "Online Drive" command from the command ring:

DBG(3496233)> RQ TRACE: rq_quesvc
DBG(3496233)> RQ REQ: cmd=0009(ONL), mod=, unit=0, bc=,
ma=, lbn=
DBG(3496233)> RQ TRACE: rq_mscp - Queue
DBG(3496233)> RQ TRACE: rq_onl
DBG(3496233)> RQ TRACE: rq_putr_unit

A response packet is placed in the response ring by the controller:

DBG(3496233)> RQ REQ: rsp=0089, sts=0023
DBG(3496333)> RQ TRACE: rq_quesvc

%BOOT-F-Failed to initialize device
HALT instruction, PC: 04C7 (BLBS 549,4C6)

The "Online Drive" command fails because no disk image was attached to
the device.

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

Re: [Simh] VAX 750 and 730 (was Is it possible to simulate the first Vaxen I ever used?)

[Matt Burke]

On 23/03/2020 19:16, Bob Supnik wrote:
> One of the problems with simulating the non-VLSI VAXen, other than the
> 780, is that the microcode is not available. Back at DEC, I had the
> 730 microcode in a huge notebook (it was 16KW), but I discarded it
> when I moved out of Hudson and downsized my document collection. We
> really need the microcode for the 750, 730, 8600/8650, 8200 (V11), and
> 8800.
>
> The various microcodes may be available in the DEC fiche collection at
> CHM, but I haven't been able to get out there to do the research, and
> travel is out of the question right now.
>
The 11/750 microcode listing is available on Bitsavers (not under the
directory you might expect though):

http://www.bitsavers.org/pdf/dec/pdp11/xxdp/fiche_200dpi/0187_CMT098.MCX_750uCod.pdf

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

Re: [Simh] EXT :Re: Mouse capture on VAXstation II/GPX (KA630) simulator V4.0-0 Current

[Matt Burke]

It looks like mouse capture is still not enabled as I'm sure the release
key should be shown in the window title bar. You can toggle the messages
region with CTRL+F2. I'll give the latest code a try to see if I can
reproduce the issues.

The QDSS does have some known issues which cause screen corruption over
time. I hope to fix these one day but debugging the QDSS can be quite
difficult.

Matt

On 19/03/2020 17:38, Supratim Sanyal wrote:
>
> Very interesting. With "qvss capture" below "cpu model", mouse now
> works (jumpy, but better than no mouse). Also, I am getting console
> replies at the top of the graphical desktop, and have lost color.
> Here's a screenshot.
>
> On 3/19/20 1:25 PM, Supratim Sanyal wrote:
>> On 3/19/20 11:09 AM, Hittner, David T [US] (MS) wrote:
>>>
>>> et cpu model=vaxstationgpx
>>>
>>> set qvss enable    ; if required – I think ‘set
>>> cpu model = vaxstationgpx’ does this implicitly
>>>
>>> set qvss capture
>>>
>> Tried this sequence:
>>
>> set cpu model=vaxstationgpx
>> set qvss enable
>> set qvss capture
>>
>> Trying to set capture after the CPU model produces this:
>>
>> "Capture Mode Can't be changed with device enabled"
>>
>> BTW, an explicit "set qvss enable" produces this twice, so I think
>> your thoughts on implicit enable is correct ...
>>
>> "QDSS Display Created.  Uncaptured Input Mode
>> QVSS Display Created.  Uncaptured Input Mode"
>>
>> -- 
>> Supratim Sanyal, W1XMT
>> 39.19151 N, 77.23432 W
>> QCOCAL::SANYAL via HECnet
> -- 
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet
>
> ___
> 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

Re: [Simh] Looking for VAX/VMS V1.0 and V2.x kits

[Matt Burke]

On 04/11/2019 14:15, Timothy Stark wrote:
> Folks,
>
>> Looking at my notes, I saw that the "V1.0 kit" (you will understand the
> apostrophes when you read the README file) is downloadable from
> http://www.9track.net/vms/BB-D782A-BE.zip
>
> Someone was looking for VMS 1.0 kit on my FB group.
> (https://www.facebook.com/moshixchannel/posts/427278254653230)
>
>  I searched for it through my mailbox and found it that came from info-vax
> group. 
>
> I tried to access that but it was gone.  I checked www.9track.net/vms and it
> does not exist anymore (404 errors). 
>
> Thanks,
> Tim
>
>

Apologies, I've re-organised things a bit and the kit is now located here:

http://www.9track.net/bits/dec/vax/vms/BB-D782A-BE.zip

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

Re: [Simh] Semi-OT: Terminal Recommendations for use with SIMH

[Matt Burke]

On 08/10/2019 21:20, Tom Perrine wrote:
>
> DEC legacy event?  Where can I find info?
>
>

http://wickensonline.co.uk/declegacy/

I'll also be there.

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

Re: [Simh] Semi-OT: Terminal Recommendations for use with SIMH

[Matt Burke]

On 29/09/2019 16:19, Zane Healy wrote:
> I’d tried ZOC7, and a couple other solutions, before settling on
> SecureCRT. I have to have a properly functioning keypad. Even then I
> still have a DEC VT420, plugged into a DECserver sitting by my Mac. I
> love my VT420’s, but at times I like to be able to cut and paste. :-)
You can cut and paste with a VT420. Hold down the 'Hold Screen (F1)' key
and use the arrow keys to position the cursor. Then use 'Select'
followed by the arrow keys to highlight the text and 'Remove' to copy.
Then you can release the 'Hold Screen (F1) key.
The text is stored in a buffer and can be pasted by holding down the
'Hold Screen (F1)' key again and pressing 'Insert Here'.

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

Re: [Simh] VAXstation 4000 Model 60

[Matt Burke]

> Why so many self-test errors?
I think David has pretty much covered this one. There are several
hardware details that are not implemented yet. Some of them may never be
implemented as they are only needed by the diagnostics. In this case the
solution will be to patch the ROM to skip the relevant test.
Interestingly the ISDN/Audio is not implemented at all and the self-test
for that passes!
> Is there anything I can do to speed up the self-test (i.e. a way to curtail
> it)?  VMS itself seems to boot OK.
Yes, you can enable fast boot with 'SET FBOOT 1' from the console. You
will need to make sure the nvr device is attached to a file. The first
boot will take a long time (as you have observed) but subsequent boots
will be a lot faster (as long as the memory size is not altered).

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

Re: [Simh] The Interconnect Task Force

[Matt Burke]

Maybe there was an upgrade kit for the RV20 like the TU81 to TA81 kit which converts it from LESI to STI.Internally the RV20 appears to use SCSI.MattOn 27 Jun 2019 10:02, Johnny Billquist  wrote:I'm pretty sure the ones I ever saw had so or sti and were connected to an hsc.  Johnny Matt Burke  skrev: (27 juni 2019 09:58:14 CEST)
On 26/06/2019 04:28, Robert Armstrong wrote: Thanks, but I was more interested in the details of LESI if they are available.  LESI was another mass storage "bus" that supported both disk and tape (albeit with exactly one example of each).There is also the RV20 write-once optical drive which used LESI.MattSimh mailing listSimh@trailing-edge.comhttp://mailman.trailing-edge.com/mailman/listinfo/simh-- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] The Interconnect Task Force

[Matt Burke]

On 26/06/2019 04:28, Robert Armstrong wrote:
> Thanks, but I was more interested in the details of LESI if they are
> available.  LESI was another mass storage "bus" that supported both disk and
> tape (albeit with exactly one example of each).
>
There is also the RV20 write-once optical drive which used LESI.

Matt

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

Re: [Simh] [simh] Scrambled text in VAXStation 3100m38 GPX graphics screen

[Matt Burke]

On 22/06/2019 20:21, paulhar...@btinternet.com wrote:
> My suspicion is that it is memory trampling in the font caching
> implementation in the emulated VCB02 device in SimH. The VCB02 device
> uses the same memory planes for font caches as for screen bitmaps -
> the manual says:
> 1.6.1.1 Font Storage and Access Fonts are stored in an undisplayed portion of 
> the bitmap. Ordinarily, a font is stored only in one plane and is transmitted 
> from that plane to itself and
> others when a character is written.   Fonts are normally stored in the 
> off-screen portion of the VCB02 bitmap.
>
> Calling Matt Burke - can you spot anything odd in your implementation of this 
> aspect of the VCB02?
>
When I released the VCB02 I mentioned that there were known problems
with VWS and UWS. Although DECwindows appeared OK with my testing it's
not surprising that it's also affected. I hope to fix this eventually
but it might not happen for a while as experience tells me it will take
many hours to track this one down.

Basically you have to enable debugging so that every drawing operating
is logged then wait for the screen to get corrupted. You then need to
count the exact pixel offset and size of the corrupted area. Next the
debug log file (which is likely several gigabytes by this point) is
searched to try and find the exact drawing operation that caused the
corruption. Then the manual needs to be consulted to find out what
subtle functionality was missed from the implementation. A change is
made, which usually breaks something else and the cycle continues :)

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 11/05/2019 00:29, Tony Nicholson wrote:
> The Ethernet routine in SIMH (vax_xs.c) uses some details from the
> VAXstation 2000 implementation of the LANCE controller chip.  I think
> the same interface is used in the VAXstation 3100 M38 being emulated -
> but I'd need to see a VAXstation 3100 Technical Manual (if it was
> produced).  One I've seen in my Google searches is a EK-A0525-TD
> manual referenced for the 3100 model 40 and 80 but no copy of it seems
> to be available online.

All of the recently added VAX simulators use the same LANCE Ethernet,
which is an AMD AM2990 chip. The only difference between them is the way
that addresses output by the AM2990 are mapped into main memory. The
LANCE is described in section 5.4 of the VAXstation 2000 Technical
Manual (EK-VTTAA-TM-001):

http://bitsavers.trailing-edge.com/pdf/dec/vax/410/EK-VTTAA-TM-001_VS2000_TechRef_Jul87.pdf

Another good source of information is the datasheet for the AM2990:

http://www.sintran.com/sintran/library/libother/extern/AM7990.pdf

These systems were built from many off the shelf parts so DEC technical
manuals are not necessarily required. Devices such as the SCSI
controller for the VAXstation 4000 M60 I wrote entirely using the
datasheet for the NCR 53C94 chip.

Other details such as the address mapping were worked out by looking at
operating system source listings and experimenting with real hardware.

There are schematics available for parts of these systems under:

http://bitsavers.trailing-edge.com/pdf/dec/vax/410/
http://bitsavers.trailing-edge.com/pdf/dec/vax/3100/

Matt

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 10/05/2019 12:42, paulhar...@btinternet.com wrote:
> Has anyone recently managed to get any of these three VAXstations
> doing a network boot? 

There are some known issues with the LANCE Ethernet controller which I'm
currently investigating. The problem could be related to the issue
reported here:

https://github.com/simh/simh/issues/698

> I then tried booting from CDROM and installing VMS (5.5-2H4 - I want to 
> replicate a particular historical system). Installing VMS and Motif went OK, 
> and I can boot from DKA0 and login to VMS, but the system looks like a 
> MicroVAX rather than a VAXstation. Do I need something in my ini file to 
> enable the graphics? I'd assumed that because these executables say 
> VAXstation, that it would be enabled by default.

You need one of these commands:

set cpu model=VAXstation
set cpu model=VAXstationGPX
set cpu model=VAXstationSPX

or the equivalent:

set vc enable
set va enable
set ve enable

Note that the SPX video option is only partially implemented and is not
really usable right now.

The executables are named VAXstation because that was the marketing name
for these systems. When the graphics are disabled it will be reported as
a VAXserver by VMS but the real systems never carried this name.

We start with the graphics disabled so that the user can choose which
video option they want to enable. Also it's possible the simulator could
have been built without SDL support.

Matt

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

Re: [Simh] VAXstation 4000/VLC Boot Failure

[Matt Burke]

On 04/05/2019 23:36, Tony Nicholson wrote:
>
> On Sun, May 5, 2019 at 8:03 AM  > wrote:
>
> Final try for this evening – I installed VAX/VMS 7.3 which went
> fine. I then installed DW Motif 125 with license. I get a crash on
> DW Motif startup. I tried this with Matt’s build of /VLC, and then
> my build, and then the latest beta 4.0 binaries.
>
>  
>
>  Fatal BUG CHECK, version = V7.3 DECWINDOWS, DECwindows
> fatal error
>
>  
>
>     Crash CPU: 00    Primary CPU: 00
>
>  
>
>     Active/available CPU masks: 0001/0001
>
>  
>
>     Current process = DECW$SERVER_0
>
>  
>
>     Register dump
>
>   Memory dump complete, dump written  to unit number 0
>
>

DECwindows will expect the LCG to be present on the /VLC, but it's not
implemented yet. You might be able to set WINDOW_SYSTEM to 0 to get
around this problem:

>>> B /R5:1 DKAxxx

SYSBOOT> SET WINDOW_SYSTEM 0

SYSBOOT> C

This should prevent DECwindows graphics drivers from being loaded at
system startup. Also update SYS$SYSTEM:MODPARAMS.DAT to reflect this
change in case you run AUTOGEN.

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 01/05/2019 13:36, m...@wickensonline.co.uk wrote:
> Matt
>
> I've built the VAXstation 4000/60 and 4000/VLC images. Is it possible to post 
> an example simh.ini file for either or both of these please, it would save me 
> some considerable guesswork!
>
> I have just reconfigured a FreeAXP emulator running on Windows which contains 
> SLAVE, formerly an AlphaServer 1000A. It serves up a cluster member disk for 
> a 4000/VLC so that will be a great test of your new systems.
>
> I previously had lots of trouble with FreeAXP and SIMH residing on the same 
> windows box, turns out that FreeAXP really doesn't like WinPCap - it crashes 
> on startup and it is very difficult to kill the image.
>
> Regards, Mark.
>
Hi Mark,

The first thing to note (if you haven't spotted it already) is that the
simulators have been merged into the Simh master branch and a number of
fixes have been applied. CD-ROM and tape drive support is now included
along with fixes to the memory sizing for the M60 and VLC.


The VAXstation 4000/60 and 4000/VLC are very similar so this simh.ini
will work for both:

; Set system memory size
;   M60 can be one of 8m, 16m, 24m, 32m, 40m, 48m, 56m, 72m, 80m, 104m
;   VLC can be one of 8m, 16m, 24m
;
set cpu 24m
;
; Attach the NVRAM device
;
attach nvr vaxstation4000.nvr
;
; Set the MAC address in the network address ROM
; This will need to match whatever your boot server is expecting
;
set nar mac=08:00:2b:40:00:60
;
; Setup local SCSI disks if required (here are a few examples)
; Also try 'help rz'
;
; set rz0 rz26
; attach rz0 disk0.img
; set rz1 disable
; set rz2 disable
; set rz3 disable
; set rz4 rrd40
; attach rz4 vms73.iso
; set rz5 tz30
; attach rz5 backup.tap
; rz6 is always disabled because this is the initiator SCSI ID
; set rz7 disable
;
; Enable LANCE Ethernet (device ESA0 under VMS)
;
set xs enable
;
; Attach Ethernet device to a host interface
;
attach xs eth0
;
; Start the simulator
;
boot cpu

The first time the ROM self-test runs after the memory size is changed
or after attaching a new NVRAM file it will perform a thorough memory
test. This can take quite a long time especially with 104MB. You will
see multiple selftest failures but don't worry about it, they're
expected for now. After the self-test completes I would recommend
enabling the fast boot option:

>>> SET FBOOT 1

This will significantly speed up subsequent restarts of the simulator.
Eventually I'll patch the ROM to skip the memory tests.

Assuming your boot server is all setup you can now boot from the Ethernet:

>>> BOOT ESA0

I haven't tested Ethernet booting on these simulators for quite some
time so I hope it works!

Let me know how it goes.

Matt

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 21/04/2019 15:13, Timothy Stark wrote:
> Wow!  I try that new simh emulator soon.
>
> Have you try implementing VAX 3100 M96/M98, VAX 4000 M106/M108, and
> VAX 4000 M90 yet?
>
> How about VAX 66x0 that provides full 32-bit addressing for up to 3.5
> GB main memory?
>
>
No, I haven't tried those yet, but some of those workstations are not
too far away with what's been done so far.

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 21/04/2019 18:44, m...@wickensonline.co.uk wrote:
> Am I right in thinking that the VAXstation 3100 M38 emulator should support 
> Ultrix/VAX?
>
Yes, I have had Ultrix working with the M30 so the M38 should be OK. The
GPX and SPX graphics options will not work right now due to outstanding
issues. I can't remember if Ultrix supports the HDC9224 (RD) disk
controller. The NCR5380 SCSI (RZ) controller is definitely supported.

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 21/04/2019 05:16, Zane Healy wrote:
> So far I’ve been trying ‘vax412’ with the various images at DKA0 and
> DKA100 (the two drives listed when you do a “SHOW BOOT” from the ROM
> prompt. At this point I fear a sample .ini file may help. :-)
> Looking at the strings at the beginning of each disk, I’m starting to wonder 
> if any are actually bootable.  I see that a couple say "is not a system 
> disk”, and the rest say “IS_KEY_DISK”, so I’m wondering if any are bootable, 
> even though it seems like I should be using InfoServer/VMS V3.5 
> (ag-r7lfa-bs.img), which says, "IS_V35  is not a system disk”.
>
> Zane
>
I managed to get a working configuration using the images from the
freeware. I've written up the procedure here:

http://www.9track.net/simh/infoserver

The target disk must be DKA100 and you need to set the boot flags to
D000 so that it boots from the [SYSD] system root.

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

Re: [Simh] More VAX Simulators

[Matt Burke]

On 20/04/2019 01:13, Zane Healy wrote:
> Very exciting!  Especially the InfoServer support, and potentially very 
> timely for what I am planning to do this weekend.  Does the InfoServer 
> simulation support backing up a system disk on a VAX or Alpha to InfoServer 
> tape?  Actually does it even support tape?
> https://www.itec.suny.edu/scsys/vms/ovmsdoc073/v73/6017/6017pro_051.html#info_ex
>
> Also, I assume I need to use the images found here?
> ftp://ftp.hp.com/pub/openvms/freeware/infoserver/freeware_readme.txt
>
> Thanks,
> Zane
>

There is some preliminary support for SCSI tape but only basic reading
commands have been implemented so far. You could backup to an InfoServer
disk though. One other thing to take note of is that I've found the
LANCE Ethernet to be a bit slow compared to real hardware. This might be
because the operating system does not notify the controller when there
are new packets to be transmitted. Instead the controller has to check
for new packets on each poll interval. This can result in a delay up to
20mS between packets whereas on real hardware it's more like 2mS.

Yes, the images from the freeware are the ones you need. It's been a
while since I last did the installation but I seem to remember something
about devices having to be at specific SCSI IDs. I'll have to experiment.

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

[Simh] More VAX Simulators

[Matt Burke]

I've put my vax4xx (VAX Workstations) branch online which is a series of
VAX simulators that are based on a similar architecture. This originally
started as the MicroVAX/VAXstation 2000 simulator that I release back in
2011, but it has been developed substantially since then to include more
feature and another 11 models of VAX. The list now includes:

MicroVAX/VAXststion 2000
InfoServer 100
InfoServer 150 VXT
MicroVAX 3100 M10/M20
MicroVAX 3100 M10e/M20e
VAXstation 3100 M30
VAXstation 3100 M38
VAXstation 3100 M76
VAXstation 4000 M60
MicroVAX 3100 M80
VAXstation 4000 VLC
InfoServer 1000

Several new devices have been developed to support these simulations
which include:

(rd) HDC9224 MFM disk controller
(rz) NCR5380 SCSI controller
(rz) NCR53C94 SCSI controller
(xs) LANCE Ethernet controller
(vc) Monochrome video controller
(va) GPX video option (partly working)
(ve) SPX video option (work in progress)

This branch is still under development. The lists above are more or less
in order in terms of how fully developed they are. The MicroVAX 2000 is
pretty much complete whereas the VAXstation 4000 M60 lacks video, sound
etc. but is still usable.

The code is available from:

https://github.com/9track/simh/tree/vax4xx

Windows executables are available at:

http://www.9track.net/simh/vax4xx/

Please try them out and let me know if you have any questions.

Thanks,

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

Re: [Simh] VAX 8200/8250

[Matt Burke]

On 07/04/2019 02:18, Ray Jewhurst wrote:
> What is the simulator called in the Makefile?  I cannot seem to find
> either a vax8200 or vax820.
>

The target is called vax820. It's defined here:

https://github.com/9track/simh/blob/vax820/makefile#L2059

There is also a project file included for Visual Studio. I realise now
though that I forgot to add vax820 to the descrip.mms file for VMS.

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

Re: [Simh] VAX 8200/8250

[Matt Burke]

On 06/04/2019 23:50, Timothy Stark wrote:
> Does simh use threads to handle MP processors?  I have other SIMH versions 
> (vaxmp and turbovax) that uses threads to take advantage of CPU cores. 
>
> I looked through your 782 code and did not see any threads handle that vaxmp 
> and turbovax uses.
>
For the VAX 8300/8350 I just run both processors in the same thread and
alternate between them on each instruction cycle. Things get a lot more
complicated when threads are involved because you have to think about
locking and synchronisation.

The VAX-11/782 is quite different as you actually run two separate
copies of the VAX-11/780 simulator and they communicate with each other
using a shared memory interconnect (simulated by shared memory on the
host operating system). One VAX-11/780 runs as the master and this is
the one that you interact with. It has access to all the I/O devices
such as disks/tapes. The other VAX-11/780 is non-interactive and can
only process workloads which are handed over from the master. This is
asymmetric multiprocessing.

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

Re: [Simh] VAX 8200/8250

[Matt Burke]

On 06/04/2019 21:28, Timothy Stark wrote:
> I was surprised to see that!  Very good news!!  Good job!  I will try that 
> soon.
>
> For 8250/8350, you need two MP processors.  Does vax820 emulate two MP 
> processors like VAX-11/782?
>
No, but I have got another branch which does. It's a fairly nasty hack
just to test the theory. Basically the two processors are run in
lock-step and it saves/restores the context of each CPU between
instruction cycles. There's a lot of overhead in that so the performance
is quite poor once you start the secondary CPU.

Bob Supnik created a simulator for the SiCortex SC1 several years ago
which shows a better way to do multiple processors in lock-step but that
would involve significant changes to the VAX CPU and MMU modules.

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

Re: [Simh] VCB02 Released

[Matt Burke]

On 06/04/2019 21:24, Timothy Stark wrote:
> I would like to see color display for other VAX emulators like VAXstation 
> 3900 and VAXstation 4000 systems. 
>
> I now found firmware images for VAX 4000 and 6000 series. 
>
> Have you successfully emulate HSC constrollers for CI interface yet?
>
VAXstation 3900 will be possible with the VCB02. Whether the console
firmware supports it is not confirmed yet.

The VAXstation 4000 series is difficult because these use the SPX and
LCG graphics controllers for which there is no documentation available.
I've been able to work out some of the details by looking at driver
source code but that only tells part of the story.

I have a HSC70 simulator which is just about (with a lot of manual
intervention) able to boot the CRONIC operating system, but there are no
CI, SDI or STI adapters implemented because almost no documentation is
available. I'm guessing the manuals that are needed are:

EK-HS572-TM - HSC50/70 Software Technical Manual
EK-HS574-TM - HSC50/70 Chip Description Technical Manual

However I've seen post from various people over the years asking for
these manuals but no replies so they are most likely lost for good. Also
I could do to obtain the ROM image from a real HSC70.

It would probably be easier to just write an MSCP server that hooks into
the virtual CI.

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

[Simh] VAX 8200/8250

[Matt Burke]

Here is a new simulator for the VAX 8200/8250 systems. Most of the key
features are there including the DWBUA BI-Unibus adapter which allows
all the existing Unibus devices to be used. The console RX50 is also
implemented.

The console processor is not simulated so it uses the same VMB trick as
the VAX-11/7xx simulators i.e. you boot directly from a device "boot
rq0" rather than "boot cpu".

You can get the code from:

https://github.com/9track/simh/tree/vax820

And Windows executable from:

http://www.9track.net/simh/vax820

Please try it out and let me know how you get on.


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

[Simh] VCB02 Released

[Matt Burke]

The long awaited VCB02 (colour graphics adapter) for VAX has now been
released. It hasn't been merged into the Simh master branch yet but for
now you can get the code from:

https://github.com/9track/simh/tree/VCB02

If you need a Windows executable then that's available here:

http://www.9track.net/simh/vax630

Here is the current status for the graphical environments that I've tested:

DECwindows - All OK as far as I can tell.
VWS - Works but leaves trails on the screen if you drag a window.
UWS - Works but certain visual elements such as window icons are
missing. Also I'm not sure the colours a are quite right. I will have to
test this on a real VAX to check.

Only captured input mode is currently supported. This must be set before
enabling the device.

sim> set qdss capture
sim> set qdss enabled

The VCB02 has only been added to the MicroVAX II simulator so far
(VAXstation II/GPX). I know there have been some discussions previously
about the MicroVAX 3900 supporting the VCB02 though I've not had success
with that yet.


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

Re: [Simh] DECwindows issues

[Matt Burke]

On 19/07/2018 06:41, Hans Hübner wrote:
> I see either one of the DECwindows processes (window or session
> manager) use more than 50% of the VAX CPU or, if I kill both
> processes, the emulator taking up 100% of its host CPU with no VAX
> process showing up in MONITOR PROC/TOPCPU.  The emulated system is too
> slow to be used, effectively.
>
I don't seem to be able to reproduce this (on Debian 9.5). I just
installed VAX/VMS 5.5-2 and DECwindows (from AG-PSA5B-RE - VMS
REMASTERED V5.5-2 BIN CDROM) using your configuration file but I only
see about 10% of the host CPU being used by Simh when logged into
DECwindows.

The only slight difference is that I'm PCAP for the Ethernet connection
rather than TUN/TAP. Do you have anything else running in the background
(DECnet, UCX, clustering etc.)? I will try to setup the same.

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

Re: [Simh] DECwindows issues

[Matt Burke]

On 16/07/2018 18:33, Hans Hübner wrote:
> If I run DECwindows on the qvss frame buffer backed by Xorg, the mouse
> cursor jumps around erratically.

You may be able to get around this problem by using captured input mode:

sim> set qvss capture

You need to do this before enabling the QVSS. Click in the video window
to capture the mouse cursor and use Ctrl+Right Shift to release it.

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

Re: [Simh] Moved my vaxuser to new standalone system and ...

[Matt Burke]

On 03/07/2018 00:09, James W. Laferriere wrote:
> So now I have a qvss window but have been wondering why after
> executing the 'boot cpu' sequence that the output/input isn't
> transfered to the qvss window ?  Just a wondering not a difficulty
> I'll try the VMS instance I have and see if it'll populate that window .
>
The MicroVAX 3900 console ROM does not support the QVSS so the console
won't transfer to that window. DECwindows does support the QVSS however
so at the end of the boot process you should get the graphical login
screen in the QVSS window.

I know some others were asking so for the record to get DECwindows
running you need to install the DECwindows kit and the appropriate
licence (DW-MOTIF). You also need to set the WINDOW_SYSTEM parameter in
SYSGEN. This has three settings:

0 - No Window System
1 - DECwindows
2 - VWS

If you want a VAX that supports the QVSS as a console then you'll need
to use the VAXstation I or VAXstation II simulators (microvax1, microvax2).

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

Re: [Simh] Moved my vaxuser to new standalone system and ...

[Matt Burke]

On 26/06/2018 23:24, James W. Laferriere wrote:
>
> With the above I am getting 
>
> sim> boot cpu
> No protocol specified
> No protocol specified
> xcb_connection_has_error() returned true
> No protocol specified
> xcb_connection_has_error() returned true
> No protocol specified
> QVSS: Error Creating Video Window: No available video device
>
> File open error, PC:  (HALT)
>
>
This looks like SDL is having problems connecting to the X server. Is
the DISPLAY environment variable set and are you able to run other
Xwindows applications from the command line? Perhaps try xdpyinfo.

It could also be an X11 access control problem. A quick search online
for X11 "no protocol specified" showed a few people having problems
running X11 applications as root (and I noticed you are running simh as
root). The problem was due to a missing .Xauthority file for the root
user. Check the environment variable XAUTHORITY.

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

Re: [Simh] Install VAX/VMS 4.4 on a simulated VAX-11/780

[Matt Burke]

On 23/03/2018 17:12, Henk van de Kamer wrote:
>
> That page I also found. However there disk gave errors and I blamed
> that on the different machine. A lot of the tuning also doesn't apply
> to the 780. I tried again with an adapted version of your ini:
>
> load vmb.exe
> set cpu idle
> attach rq0 vms44sys.dsk
> attach rq1 vms040stb.rx3
> attach ts bb-bt05c-be.tap
> ;attach cs vms044mup.rx1
> set console log=logs/vms44.log
>
This all looks fine but as you are using an old version of Simh you will
need to add 'set rq1 rx33' to your ini file. The rq1 device will not
automatically adjust to the size of the image like it does in newer
versions. Also the CS device is called RX in the older version.

If you start from the heading 'Setting up the VAX-11/782' and ignore
anything relating to the ma0 and ma1 devices then the instructions on my
website should work just fine for a standard VAX-11/780 up to the point
where is says 'The installation of VAX/VMS is now complete'.

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

Re: [Simh] VMS 1.5 installable?

[Matt Burke]

On 18/10/2017 14:16, Wilm Boerhout wrote:
>
> Wonderful. So most likely, this tape is in DSC2 format as well ?
>
Yes, it's DSC2 format.

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

Re: [Simh] VMS 1.5 installable?

[Matt Burke]

You may also want to try VAX/VMS 1.0 (or as close as you can get to it):

http://www.9track.net/vms/BB-D782A-BE.zip

This is not taken from an original tape. It's something I reconstructed
from a disk containing early VAX/VMS source and binaries. The dates
indicate that this is earlier than VAX/VMS 1.5.
Hopefully someone can find an original at some point.

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

Re: [Simh] DSC Disk Save and Compress

[Matt Burke]

On 17/10/2017 21:55, William Pechter wrote:
>  My first job at DEC was installing VMS 2.0 on 11/780s.  Standalone DSC was 
> loaded from the 11/780 front end floppies IIRC.
>

Part numbers are as follows:

AS-E808G-YE - ESZCCC1 11/780 S/A DSC2 FLP (RX9)
AS-E808I-YE - STAND/ALONE 11780 DSC2 FLP1
AS-J831A-BE - STAND/ALONE 11780 DSC2 FLP2

Unfortunately I don't have any images.

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

Re: [Simh] New simulator - VAX-11/782

[Matt Burke]

On 25/05/2017 04:03, Sergey Oboguev wrote:
> Superficially looking at (AS)MP VMS code, it appears that the
> following should (hopefully) suffice for correct operation:
>
> 1. BBSSI and BBCCI should acquire a lock when accessing the memory
> location. A simplistic implementation may use one lock for the whole
> memory (or the whole MA780 memory bank). A more sophisticated
> implementation may use a bucket of locks, with a particular physical
> address within an MA bank mapping to a corresponding lock in the
> bucket (with a lock being shared by a range of MA physical addresses)
> -- but that would probably be an overkill for 2-CPU config which is
> not particularly heavy on synchronization.

My plan was to use just one global lock which would be set on the read
cycle and cleared on the write cycle.

>
> 1.2. VMS itself does not appear to use anything other than BBSSI and
> BBCCI in the ASMP code. However applications or libraries using the
> multiprocessing may, so for their sake the same applies to other
> interlocked instructions as well. Those applications or libraries
> might also conceivably use a higher rate of locking (justifying the
> bucketing of locks in this case) -- but do they even exist in the
> first place?

Chapter 4 of the VAX-11/782 User's Guide recommends the interlocked
instructions for user written code so they all need to be supported. We
really need the MA780 technical description of the field maintenance
print set to understand how it handles the read-interlocked SBI cycle.

>
> 2. When sending out an IPI, the sending VCPU thread should execute a
> write memory barrier right before writing to the interrupt register.
>
> 3. When receiving an IPI and before handling it, the receiving VCPU
> thread should execute a read memory barrier matching the barrier in
> (2). An obvious implementation would be for (2) and (3) to acquire a
> lock on the "interrupt pending" register of the CPU that is the target
> of the IPI.

I probably should have researched memory barriers a bit more. I knew a
little bit about them but wasn't sure if they were needed here. The
problem may also exist for the rest of the shared memory.

>
> As is always with legacy MP code though, it is a bit of a gamble.
> Modern host processors have different cache coherency model than that
> of the 780 CPUs. Thus it is possible for some sequences that worked on
> the 11/78x multiprocessor to start failing when emulated on x86 or
> other contemporary host CPU. Only a detailed review of the code with
> respect to the cache coherency assumed by the code can tell.
>
> But do we even know how the 780 cache operates?
> Is it write-through or lazy writeback?
> Do interlocked instructions (such as BBSSI/BBCCI) invalidate the 780
> read cache?
> Do they commit pending writebacks from the cache to MA780/main memory
> (MS780) before the instruction completion?

Here is extract from the VAX-11/782 User's Guide that partly answers the
question:

"Each MA780 shared memory subsystem should have the cache invalidation
map option. This option reduces traffic on the Synchronous Backplane
Interconnect (SBI) by reducing the number of cache invalidate requests
sent to each processor. By keeping track of which locations in MA780
memory have been placed in the cache of each processor, the option
allows cache invalidate requests to be sent only to the processor(s)
whose cache contains the location that has been invalidated."

So it looks like the port invalidation control register contains a mask
of the SBI nodes that need to have cache invalidate requests sent to
them. The ASMP code sets the bit for nexus 0 (CPU) as part of the
initialisation.

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

Re: [Simh] New simulator - VAX-11/782

[Matt Burke]

On 21/05/2017 15:54, Tim Stark wrote:
> Interesting! Thanks for let us know about MP version of VAX-11/780. Will it 
> be 787/789 emulation (VAX-11/785)? How about 784 (4 processors)? I recommend 
> atomic variables for interlocking. Check C++ reference for more information. 
> It requires least C++11 revisions (least GCC version 4.7). Also it now 
> provides threads internally. I will use them in my MSE emulator. 
>

Yes, it covers the 787/789 too. Just change the CPU model from 11/780 to
11/785:

sim> set cpu model=785

This VAX-11/784 is also covered although there seems to be a few issues
here that I need to investigate. Note that VAX/VMS does not support the
VAX-11/784 for multi-processing. You have to write your own code to make
use of the MA780 shared memory.

The sim_ipc module can provide locking for the shared memory. The bit
that needs working out is how to dispatch to ipc_lock for the
read-interlocked memory accesses. I have some ideas about how to do it.

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

Re: [Simh] New simulator - VAX-11/782

[Matt Burke]

>> On May 20, 2017, at 12:00 PM, Paul Koning  wrote:
>>
>> Interesting.  So you have the two CPUs as two processes?  I wonder if doing 
>> them as threads in a single process might be more straightforward.  I did an 
>> implementation of dual CPU CDC 6000 emulation that way (an extension to Tom 
>> Hunter's DtCyber).  Posix threads (pthread) work nicely, and semaphores 
>> (which aren't strictly part of pthreads but are often found alongside such 
>> implementations) often come in handy as well.
>>
>>  
Yes that's correct. The reason I implemented the VAX-11/782 in this way
is that it more closely replicates the arrangement of the physical
hardware. The real VAX-11/782 is two separate VAX-11/780 systems and the
only connection between them is the MA780 shared memory. For the
VAX-11/782 multi-processing configuration, the secondary VAX-11/780
(attached processor) boots from the shared memory and does not interact
with the console. For the VAX-11/784 each VAX-11/780 system boots from
it's own system disk and interacts with the console normally.
Multi-processing is then achieved via user written code that interacts
via the MA780 shared memory. It would be difficult to simulate the
VAX-11/784 via threads. The other reason for this choosing this
implementation is that it requires minimal changes to the existing VAX
simulator code.

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

[Simh] New simulator - VAX-11/782

[Matt Burke]

Ok, so now it's time to reveal the new 'device' I've been working on
that I mentioned a few days ago. It is in fact the MA780 multi-port
memory as used by the VAX-11/782. Simulator source is now on Github and
binaries (for Win32) are available on my website along with a guide on
how to setup VAX/VMS for asymmetric multi-processing:

http://www.9track.net/simh/vax782/

This simulator relies on a new module 'sim_ipc' which has O/S specific
code for inter-process communication. This module should work on at
least Windows, VMS and POSIX compliant UNIX variants but no doubt some
more work will be required in this area to make it truly portable. There
are a few known issues as noted on my website but please try this out
and let me know how you get on.

I suspect the simulation is not totally accurate as there was very
little documentation available to base this on. Does anyone have a copy
of the following manuals?

EK-MA780-TD - MA780 Technical Description
MP-00826-00 - MA780 Field Maintenance Print Set

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

Re: [Simh] Problem with MT_ASTLVL on the VAX-11/780

[Matt Burke]

On 18/05/2017 00:18, Johnny Billquist wrote:
>
> Hum. Do I remember wrong? I seem to remember that when you MOVB to a
> register, the value should be sign extended. So not just the low byte
> should have been modified.
>
> Johnny
>

I think you may be thinking of MOVZBL (and MOVZWL for words).

Matt

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

Re: [Simh] DECserver (terminal server) emulation?

[Matt Burke]

On 08/04/2017 21:37, Tim Stark wrote:
> I am still looking for DS 300 tech docs.
>
>  
>

I can't find where I downloaded this from but here is the DECserver 300
Technical Description:

http://www.9track.net/decserver/ek-a0367-tm-001.pdf

Matt

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

Re: [Simh] DEC VT emulators on MAME

[Matt Burke]

On 10/04/2017 23:33, Johnny Billquist wrote:
> The VT330 and VT340 have an external cartridhe that plugs into a slot
> in the back, and which holds most of the code.

The VT330 and VT340 have the ROM cartridge slot, but for the VT330+ and
VT340+ it's all internal.

Matt

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

Re: [Simh] VT240, VT340 and DS200/300 HW specs info

[Matt Burke]

On 09/04/2017 06:11, Tim Stark wrote:
>  
>
> VT340 uses 8031/8051 processor with 2681 and custom graphics
> processor. It uses 4 DC 322 Viper Gullwin (each bitmap plane).
>
> (I can’t find DC 7051 (timing generator) and DC 322/323 (Adder/Viper)
> tech docs so far).  It uses 4 bitmap planes.
>
> It supports up to 4096 colors but can only select 16 colors from them.
>
>  
>

The Adder and Viper chips are documented in EK-104AA-TM-001 - VCB02
Video Subsystem Technical Manual.

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

[Simh] CI Code Released

[Matt Burke]

As Mark mentioned recently I've already done quite a bit of work on a CI
and DSSI simulation for the VAX. I originally started working on this
quite a few years ago and I did have it mostly working at one point.

I've taken my latest development version and tried to tidy it up a bit
and merge it into the latest Simh code. I haven't had chance to work on
this properly for quite a while now so I'm just going to release what
I've got as there seems to be quite a bit of interest. The result is in
a branch on Github:

https://github.com/9track/simh/tree/CI

Unfortunately this latest version does not quite work. It seems that
something got broken in one of the more recent updates. I might get some
time later this week to debug it. I don't think it will be anything major.

The other problem is that this was based on a much earlier release of
Simh and the sim_sock module has changed beyond recognition. To allow
people to be able to build this I've temporarily bundled the old
sim_sock into the repo as ci_sock with some changed to add multicast
sockets.

To get the CI port to work you will need console media containing the
microcode. The O/S will not attempt to initialise the port unless it
finds these files. The actual microcode is not used by the simulation.
For convenience I've uploaded some suitable console images here:

http://www.9rack.net/simh/750console.zip
http://www.9rack.net/simh/780console.zip
http://www.9rack.net/simh/8600console.zip

To setup the CI port use commands similar the the following:

; Enable the CI port
sim> set ci en

; Set the port number (range 0-15). This would be set by jumpers on the
real adapter
sim> set ci node=4

; Set the (unique) TCP port number for virtual circuits. Other
simulators will use this port to establish virtual circuits to this node
sim> set ci port=3818

; Attach the CI port to a UDP multicast group. This will be used so that
nodes can 'discover' each other prior to a virtual circuit being opened.
This should be the same address and port on all nodes belonging to the
same CI. The address should be in the range 239.0.0.x
sim> att ci 239.0.0.37:3812

Feel free to ask any questions and I'll try to help where I can.

The sources of information I used when developing this were:

Chapter 5 of EY-9222E-SA-0001 - VAXcluster Maintenance Student Workbook
Volume 1
EK-CI750-TD - CI750 Hardware Technical Description
VMS source listings
Ultrix source listings

There are more simulations in the pipeline (HSC70, VAX 8200, VAXstation
2000, VAXstation 3100...). Hopefully I'll get these released soon too.

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

Re: [Simh] Hardware fidelity in the VAX family simulators

[Matt Burke]

On 08/07/2015 22:39, Bob Supnik wrote:
 It looks to me like the 750, 730, 8600 are cut-and-paste jobs on the
 780, and the MicroVAX I and II on the 3900. I admit there are strong
 family resemblances and, in some cases, reuse of hardware (the 8600
 uses some of the 780 IO adapters), but as Ultrix proved, running VMS
 is an insufficient proof of correctness. Without reading (and
 implementing) the gory details of all the system-specific hardware,
 something is going to break.

Yes, they were. It was the best I could do at the time as I had almost
no knowledge of the VAX architecture when I started writing these
simulators. My first encounter with a VAX (and VMS) was in 2005 during
my university work experience year (although to this day I've never seen
a real 730, 750, 8600 or MicroVAX I).

The available documentation wasn't always clear about how certain
components should work and in these cases the correct functionality had
to be inferred from VMS and Ultrix source listings.

 And if the goal is just to run VMS, why bother with variant models?

Because I thought it would be fun and that I might learn something by
doing it. Both objectives were achieved.

 The 780 and 3900 between them cover the complete history of VAX/VMS,
 Ultrix, and all the BSD variants.

Although you do need the VAXstation I or VAXstation II to run VWS.

 So my challenge to the community is twofold. First, is there more
 documentation on the variants available somewhere? I haven't found
 microcode sources or listings for the 750, 730, MicroVAX I, or 8600,
 for example. Second, are people prepared to adopt a model, read its
 documentation, and clean it up?

I hope so. I never expected them to be 100% perfect but I was hopeful
that the community based testing and development would eventually ensure
they worked correctly.

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

Re: [Simh] Feature request

[Matt Burke]

On 05/12/2014 22:41, Kevin Handy wrote:
 It would also be nice to be able to leave notes/reminders in the
 scripts telling what the script is about or what it is doing at a
 specific point.


The comment character is a semicolon in Simh scripts. I see what you
mean about the first line though.

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

Re: [Simh] Standalone boot on vax8600?

[Matt Burke]

On 08/07/2014 12:50, Johnny Billquist wrote:
 On 2014-07-08 01:50, Henry Bent wrote:
 How are standalone programs loaded and run on the 8600?  On the 7x0 I
 can do load -o boot 0 and run 2 and that will run a standalone
 boot.  When I do that in the 8600 sim I get a newline and then the
 program just loops forever.

 Alternately, does anyone know the right way to load bootblocks on an ra
 disk in Ultrix 1 or 2 so that I can boot off of the disk directly?
 Everything I've tried just ends up giving a %BOOT-F-Unable to locate
 BOOT fil message from vmb.exe.

 VMB needs to have R5 set to specific values to boot Ultrix.
 If I remember right, bit 3 (0x8) needs to be set in R5 in order for
 VMB to just load the boot block from the device and start executing
 that instead of trying to look for specific files inside a Files-11
 filesystem.

 But on a rel 86x0, you can also load other binaries from the console
 device, and just start them. For old versions of Ultrix, I seem to
 remember that this is what they did, before VMB gained the capability
 to boot from a boot block.


The value 8 is correct for R5. To boot this in simh use:

sim b rq0 /r5:8

On a side note I think this flag is not required on later VAX system
such as the MicroVAX II. The ROM code seems to work out what to do.

'load -o' is supported on the VAX 8600 so I suspect there is another
issue. It could be a problem with the console device as I think someone
has previously mentioned that there are some issues with my
implementation (unless this been fixed now?)

Matt
___
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)
 david.hitt...@ngc.com 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
 [mailto: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 mailto: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 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

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

Re: [Simh] Unaligned references

[Matt Burke]

Bob,

It all looks OK to me. The fact that both I/O and register space have
unaligned read/write functions should provide enough flexibility to
support the variety of VAX models now simulated. I still have a few
details to work out for these other models. I may also need to do
something about accesses to Qbus memory space (0x3000 upwards) as I
guess this should behave the same as Qbus I/O space? It's not really an
issue for CVAX at the moment as accesses reflect to main memory.

Matt

On 26/11/2013 01:33, Bob Supnik wrote:
 I have a design with probe coding for fixing the unaligned IO space
 problem recently uncovered in the VAX emulator.

 Because it tears up the core of unaligned processing, I'd like some
 other eyes to look at it before I start editing code and debugging.

 My plan is:

 a) verify all cases of unaligned access to memory by simple tests
 (read B, W, L, Q unaligned at every possible offset; write B, W, L, Q
 unaligned at every possible offset)
 b) run HCORE, the hard core diagnostic - this will test unaligned
 references with memory management
 c) verify that the VAX 780 still runs VMS (unaligned IO references are
 not allowed, so only unaligned memory references need to be working
 correctly)
 d) verify all cases of unaligned access to Qbus IO space - a bit
 tricky, as I need to find IO registers that are not sparse
 e) verify that CVAX still runs VMS
 f) turn over the changes to the community for further testing

 The design paper is attached, for review.

 /Bob



 ___
 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