[Simh] EXT : VAXstation 4000 Model 60
Johnny Billquist
bqt at softjar.se
Fri Jul 12 14:26:43 EDT 2019
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-bounces at trailing-edge.com] On Behalf Of Jeremy Begg
> Sent: Friday, July 12, 2019 8:59 AM
> To: simh at 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: jeremy at 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 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
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the Simh
mailing list