As far as I am aware, it was only some models in the 3100 series that
used the shorter SCSI commands in the boot rom, which caused issues with
the boot disk. However, I'm not sure that exact thing is the problem.
You might very well have some display issues that pop up in the boot
monitor, even though the system will boot perfectly fine from a larger disk.
Johnny
On 2019-07-12 20:16, Hittner, David T [US] (MS) wrote:
Why so many self-test errors?
Because the simulator is relatively new, and getting it running an OS was more
important than passing all of the diagnostics. It can be quite difficult to
pass hardware diagnostics, particularly since some hardware diagnostics are
timing dependent, which is tough to get right in a simulation. Many (if not
most) of the simulators cannot fully pass all OEM diagnostics, but they work
well enough to run the Operating Systems correctly. See the recent thread about
simulating disk formatting behavior, and Bob Supnik's multiple papers about
getting the hardware details right on the SIMH web site.
Usually simulators will be altered over time to be able pass more diagnostics,
as people help refine the simulation.
I assume the "NUMBYTES" value for DKA300 is an artifact of the SHOW DEV command
not coping with such a large disk.
Many of VAX line have difficulty in dealing with SCSI disks of greater than 1.07 GB and
8GB due to the number of bits allowed for the LBN in the various smaller SCSI command
blocks of the time. If the disk seems to be undersized, you are probably experiencing the
notorious "disk wrap" that occurred when you attach a disk larger than what the
SCSI commands can accommodate and map. Try reducing the size of your user-sized disk
until you see the correct value recognized.
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.
You can always alter the boot ROM to skip the tests. The boot ROM tests take a
specific length of time, and the simulator is faithfully running the tests,
using the simulated wait times to allow the simulated devices time to respond.
David
-----Original Message-----
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Jeremy Begg
Sent: Friday, July 12, 2019 8:59 AM
To: simh@trailing-edge.com
Subject: EXT :[Simh] VAXstation 4000 Model 60
Hi,
I am trying to set up SIMH on a new Linux server, an Intel NUC8i3BEH with 16GB
RAM and 250GB SSD running Ubuntu Server 18.04 LTS.
I've built the VAXstation 4000 Model 60 simulator on this system and I didn't
notice any errors while building. (The build itself was very quick.)
VAXstation 4000-60 (KA46) simulator V4.0-0 Current git commit id:
5e8f4803
I've prepared two ODS-2 VMS disk images and attached them to RZ2 and RZ3,
respectively.
When I run BOOT CPU it loads the VAXstation boot ROM from the internal copy and
starts the system self-tests, which take quite a few minutes to run -- just
like the real hardware :-(
The self test results in several errors. Here's the transcript:
Loading boot code from internal ka46a.bin
KA46-A V1.4-38E-V4.2
08-00-2B-02-10-2C
104MB
?? 001 3 DZ 0032
?? 001 4 CACHE 0768
?? 001 7 IT 1152
?? 001 8 SYS 0128
?? 001 9 NI 0024
>>> show dev
VMS/VMB ADDR DEVTYPE NUMBYTES RM/FX WP DEVNAM
REV
------- ---- ------- -------- ----- -- ------
---
ESA0 08-00-2B-02-10-2C
DKA200 A/2/0 DISK 2.15GB FX RZ23
0A18
DKA300 A/3/0 DISK 20.13MB FX RZ23
0A18
..HostID.. A/6 INITR
>>>
Why so many self-test errors?
I assume the "NUMBYTES" value for DKA300 is an artifact of the SHOW DEV command
not coping with such a large disk.
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.
Here's my SIMH initialisation script:
; set memory size to 104MB
set cpu 104m
set cpu idle=vms
set cpu instructions=packed,extended,noemulated
; set cpu autoboot
set cpu conhalt
;
; change the 'escape' character from ^E to ^P
set console wru=10
;
; Create and attach two SCSI disks
attach rz2 eric_SYSTEM.dsk
; set rz3 rzuser=8427936
attach rz3 eric_USER.dsk
;
; Disable remaining disk devices
set rz0 disable
set rz1 disable
set rz4 disable
set rz5 disable
set rz7 disable
;
boot cpu
I'm yet to attach the ethernet interface, which won't use tun/tap.
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: jer...@vsm.com.au |
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
