MicroVAX I simulator microvax1 not booting VMS Standalone Backup

[vaxorcist]

The MicroVAX I simulator microvax1 does not boot VMS Standalone Backup.

This was tested with VMS Standalone Backup versions V4.7 and V5.5-2 on RX50 images. See below for V4.7 (same result for V5.5-2):

Logging to file "STABA047-MV1.log" at Tue Apr 11 08:36:51 2023
MicroVAX I (KA610) simulator Open SIMH V4.1-0 Current
    Simulator Framework Capabilities:
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
    Host Platform:
        Compiler: GCC 10.2.1 20210110
        Simulator Compiled as C arch: x64 (Release Build) on Mar 20 2023 at 08:30:39
        Build Tool: simh-makefile
        Memory Access: Little Endian
        Memory Pointer Size: 64 bits
        Large File (>2GB) support
        SDL Video support: SDL Version 2.0.14, PNG Version 1.6.37, zlib: 1.2.11
        PCRE RegEx (Version 8.39 2016-06-14) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        Ethernet packet info: libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
        OS: Linux think 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
        Processor Name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
        tar tool: tar (GNU tar) 1.34
        curl tool: curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
        git commit id: 86b19c76+uncommitted-changes
        git commit time: 2023-02-26T19:53:06-0500
/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/microvax1.ini-6> ATT RQ0 uVMS040.R52
%SIM-INFO: RQ0: 'uVMS040.R52' Contains ODS2 File system
%SIM-INFO: RQ0: Volume Name: MICROVMS     Format: DECFILE11B   Sectors In Volume: 60480
/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/microvax1.ini-8> ATT RQ1 STABA047-1.RX5
%SIM-INFO: RQ1: 'STABA047-1.RX5' Contains ODS2 File system
%SIM-INFO: RQ1: Volume Name: SYSTEM_1     Format: DECFILE11B   Sectors In Volume: 800
sim> b rq1
%SIM-INFO: Loading boot code from internal ka610.bin
.2..1.
%BOOT-F-ERROR, Program image not found DUA
Software done, PC: 000008BB (BRB 8B4)
sim> exit
Goodbye
Log file closed

It should work as tested with the microvax2 simulator:

Logging to file "STABA047-MV2.log" at Tue Apr 11 08:37:08 2023
MicroVAX II (KA630) simulator Open SIMH V4.1-0 Current
    Simulator Framework Capabilities:
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
    Host Platform:
        Compiler: GCC 10.2.1 20210110
        Simulator Compiled as C arch: x64 (Release Build) on Mar  4 2023 at 08:42:20
        Build Tool: simh-makefile
        Memory Access: Little Endian
        Memory Pointer Size: 64 bits
        Large File (>2GB) support
        SDL Video support: No Video Support
        PCRE RegEx (Version 8.39 2016-06-14) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        Ethernet packet info: libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
        OS: Linux think 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
        Processor Name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
        tar tool: tar (GNU tar) 1.34
        curl tool: curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
        git commit id: 86b19c76+uncommitted-changes
        git commit time: 2023-02-26T19:53:06-0500
/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/microvax2.ini-4> SET CPU 8M
%SIM-ERROR: CPU device: Non-existent parameter - 8M
/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/microvax2.ini-6> ATT RQ0 uVMS040.R52
%SIM-INFO: RQ0: 'uVMS040.R52' Contains ODS2 File system
%SIM-INFO: RQ0: Volume Name: MICROVMS     Format: DECFILE11B   Sectors In Volume: 60480
/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/microvax2.ini-8> ATT RQ1 STABA047-1.RX5
%SIM-INFO: RQ1: 'STABA047-1.RX5' Contains ODS2 File system
%SIM-INFO: RQ1: Volume Name: SYSTEM_1     Format: DECFILE11B   Sectors In Volume: 800
sim> boot cpu
%SIM-INFO: Loading boot code from internal ka630.bin

KA630-A.V1.3

Performing normal system tests.

  5..4..3..

Tests completed.

>>> boot dua1

  2..1..0..

Please remove the volume "SYSTEM_1" from the console device.

Insert the next standalone system volume and enter "YES" when ready: 
Simulation stopped, PC: 0000BFDB (BBC #7,R0,BFD8)
sim> exit
Goodbye
Log file closed

For the microvax1.ini and microvax2.ini as well as the Standalone Backup images see: microvax1_boot-problem.zip

[markpizz]

The key problem you are seeing here is the fact that the STABACKIT.COM procedure for this version of VMS generates a standalone backup kit, but that kit is not 100% compatible with the capabilities of the MicroVAX I boot ROM's code. Specifically, the logic in the system's ROM looks for the file it is booting in [SYSEXE] of the disk being booted.

You can "fix" the generated standalone backup disk by entering these commands after creating the standalone backup media before attempting to boot it:

$ mount dua1: STANDBACKUP
$ set def dua1:[000000]
$ set file/enter=[000000]sysexe.dir [sys0]sysexe.dir

This will then be bootable on a microvax1 and other vax simulators. If you're working with RX50 floppy standalone backup, then you've got to perform the above fix on EACH of the 3 standalone backup floppy disks.

This might also be the solution for https://github.com/simh/simh/issues/992. I'll leave that to you to confirm... :-)

[vaxorcist]

Suggested fix applied to the RX50s; one problem solved, another problem occurred - the boot process proceeds, but hangs in an endless loop after issuing the first output:

%SIM-INFO: Loading boot code from internal ka610.bin
.2..1..0.

  MicroVMS Version V4.0 15-SEP-1984 22:29

Simulation stopped, PC: 80008B1F (BRB 80008B1F)
sim> c

Simulation stopped, PC: 80008B1F (BRB 80008B1F)
sim> c

Simulation stopped, PC: 80008B1F (BRB 80008B1F)
sim> c

Simulation stopped, PC: 80008B1F (BRB 80008B1F)
sim>

The test bed (simh and VMS images) are still the same.

What is VERY strange is the fact, that the Standalone Backup RX50 floppies images were not generated using STABACKIT.COM; they are image made from original MicroVMS V4.0 installation floppies. How could a MicroVAX I owner have installed VMS on his computer back then with the Standalone Backup RX50 floppies not working?

I'm very curious about your ideas!

[vaxorcist]

I tried your latest simh release, but the "hang" remains.

sim> sh ver
MicroVAX I (KA610) simulator V4.0-0 Current
    Simulator Framework Capabilities:
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 15
    Host Platform:
        Compiler: GCC 10.2.1 20210110
        Simulator Compiled as C arch: x64 (Release Build) on May  1 2023 at 09:08:20
        Build Tool: simh-makefile-single-compile
        Memory Access: Little Endian
        Memory Pointer Size: 64 bits
        Large File (>2GB) support
        SDL Video support: SDL Version 2.0.14, PNG Version 1.6.37, zlib: 1.2.11
        PCRE RegEx (Version 8.39 2016-06-14) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        Ethernet packet info: NAT, TAP, UDP, PCAP: libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
        OS: Linux think 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
        Processor Name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
        tar tool: tar (GNU tar) 1.34
        curl tool: curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
        git commit id: d0a1b135
        git commit time: 2023-04-30T15:14:54-10:00
sim> 

[markpizz]

Suggested fix applied to the RX50s; one problem solved, another problem occurred - the boot process proceeds, but hangs in an endless loop after issuing the first output:

%SIM-INFO: Loading boot code from internal ka610.bin .2..1..0.

MicroVMS Version V4.0 15-SEP-1984 22:29

Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim> c

The test bed (simh and VMS images) are still the same.

Hmmm... It works for me:

MicroVAX I (KA610) simulator V4.0-0 Current        git commit id: d0a1b135
sim> dir *.rx5
 Directory of D:\Projects\vax\MicroVMS

05/01/2023  03:58 AM           410,112 STABA047-1.RX5
05/01/2023  03:58 AM           409,600 STABA047-2.RX5
05/01/2023  03:59 AM           409,600 STABA047-3.RX5
               3 File(s)         1,229,312 bytes
               0 Dir(s)
sim> att rq3 STABA047-1.RX5
%SIM-INFO: RQ3: 'STABA047-1.RX5' Contains ODS2 File system
%SIM-INFO: RQ3: Volume Name: SYSTEM_1     Format: DECFILE11B   Sectors In Volume: 800
sim> boot DUA3
%SIM-INFO: Loading boot code from internal ka610.bin
.2..1..0.
Please remove the volume "SYSTEM_1" from the console device.

Insert the next standalone system volume and enter "YES" when ready:
Simulation stopped, PC: 0000C3D8 (MFPR #20,R0)
sim> det rq3
sim> att rq3 STABA047-2.RX5
%SIM-INFO: RQ3: 'STABA047-2.RX5' Contains ODS2 File system
%SIM-INFO: RQ3: Volume Name: SYSTEM_2     Format: DECFILE11B   Sectors In Volume: 800
sim> c
YES

Resuming load operation on volume "SYSTEM_2", please stand by . . .

   VAX/VMS Version V4.7 28-Oct-1987 13:00

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)  1-MAY-2023 4:01
Please remove the volume "SYSTEM_2" from the console device.

Insert the standalone application volume and enter "YES" when ready:
Simulation stopped, PC: 80008B1F (BRB 80008B1F)
sim> det rq3
sim> att rq3 STABA047-3.RX5
%SIM-INFO: RQ3: 'STABA047-3.RX5' Contains ODS2 File system
%SIM-INFO: RQ3: Volume Name: BACKUP       Format: DECFILE11B   Sectors In Volume: 800
sim> c
yes

Resuming load operation on volume "BACKUP", please stand by . . .

%BACKUP-I-IDENT, Stand-alone BACKUP V4.7; the date is  1-MAY-2023 04:01:21.77
$

I suggest that you try WITHOUT enabling IDLE. If things work fine without idle, then create a separate issue to address the idle issue.

There was a relatively long time between when the "VAX/VMS Version V4.7 28-Oct-1987 13:00" message appeared and the prompt for the time of day occurred.

What is VERY strange is the fact, that the Standalone Backup RX50 floppies images were not generated using STABACKIT.COM; they are image made from original MicroVMS V4.0 installation floppies. How could a MicroVAX I owner have installed VMS on his computer back then with the Standalone Backup RX50 floppies not working?

You didn't provide these MicroVMS V4.0 standalone backup floppies in your https://github.com/open-simh/simh/files/11197511/microvax1_boot-problem.zip

I used the ones from your zip in the above successful run. I did not use your .ini file.

I'm very curious about your ideas!

As for how this might have been needed with DEC distributed media, I really can't say. We are using the ka610.bin ROM image that Matt Burke provided when he initially put together the MicroVAX 1 simulator. Maybe the one you have in your personal MicroVAX I and the one he was working with are different. I discarded my personal MicroVAX I as soon as I got my hands on a MicroVAX II processor, so I can't personally check. The MicroVAX I documents on bitsavers.org suggest that [SYSEXE] wouldn't be necessary, but looking for text in the ka610.bin file actually mentions [SYSEXE] and [SYS0.SYSMAINT], but no [SYS0.SYSEXE]. The MicroVAX I boot ROM can't be accessed directly from the console, since it is only references under the covers by the MicroVAX I firmware. You'd have to remove the ROM and read it somewhere...

[vaxorcist]

Sorry, I forgot to send you the MicroVMS V4.0 Standalone Backup floppy images (2). IDLE or NOIDLE doesn't matter, already tried that. Shall I open another issue?

Thanks!

Ulli

Am Mo., 1. Mai 2023 um 16:15 Uhr schrieb Mark Pizzolato < @.***>:

Suggested fix applied to the RX50s; one problem solved, another problem occurred - the boot process proceeds, but hangs in an endless loop after issuing the first output:

%SIM-INFO: Loading boot code from internal ka610.bin .2..1..0.

MicroVMS Version V4.0 15-SEP-1984 22:29

Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim> c

The test bed (simh and VMS images) are still the same.

Hmmm... It works for me:

MicroVAX I (KA610) simulator V4.0-0 Current git commit id: d0a1b135 sim> dir *.rx5 Directory of D:\Projects\vax\MicroVMS

05/01/2023 03:58 AM 410,112 STABA047-1.RX5 05/01/2023 03:58 AM 409,600 STABA047-2.RX5 05/01/2023 03:59 AM 409,600 STABA047-3.RX5 3 File(s) 1,229,312 bytes 0 Dir(s) sim> att rq3 STABA047-1.RX5 %SIM-INFO: RQ3: 'STABA047-1.RX5' Contains ODS2 File system %SIM-INFO: RQ3: Volume Name: SYSTEM_1 Format: DECFILE11B Sectors In Volume: 800 sim> boot DUA3 %SIM-INFO: Loading boot code from internal ka610.bin .2..1..0. Please remove the volume "SYSTEM_1" from the console device.

Insert the next standalone system volume and enter "YES" when ready: Simulation stopped, PC: 0000C3D8 (MFPR #20,R0) sim> det rq3 sim> att rq3 STABA047-2.RX5 %SIM-INFO: RQ3: 'STABA047-2.RX5' Contains ODS2 File system %SIM-INFO: RQ3: Volume Name: SYSTEM_2 Format: DECFILE11B Sectors In Volume: 800 sim> c YES

Resuming load operation on volume "SYSTEM_2", please stand by . . .

VAX/VMS Version V4.7 28-Oct-1987 13:00

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 1-MAY-2023 4:01 Please remove the volume "SYSTEM_2" from the console device.

Insert the standalone application volume and enter "YES" when ready: Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim> det rq3 sim> att rq3 STABA047-3.RX5 %SIM-INFO: RQ3: 'STABA047-3.RX5' Contains ODS2 File system %SIM-INFO: RQ3: Volume Name: BACKUP Format: DECFILE11B Sectors In Volume: 800 sim> c yes

Resuming load operation on volume "BACKUP", please stand by . . .

%BACKUP-I-IDENT, Stand-alone BACKUP V4.7; the date is 1-MAY-2023 04:01:21.77 $

I suggest that you try WITHOUT enabling IDLE. If things work fine without idle, then create a separate issue to address the idle issue.

There was a relatively long time between when the "VAX/VMS Version V4.7 28-Oct-1987 13:00" message appeared and the prompt for the time of day occurred.

What is VERY strange is the fact, that the Standalone Backup RX50 floppies images were not generated using STABACKIT.COM; they are image made from original MicroVMS V4.0 installation floppies. How could a MicroVAX I owner have installed VMS on his computer back then with the Standalone Backup RX50 floppies not working?

You didn't provide these MicroVMS V4.0 standalone backup floppies in your https://github.com/open-simh/simh/files/11197511/microvax1_boot-problem.zip

I used the ones from your zip in the above successful run. I did not use your .ini file.

I'm very curious about your ideas!

As for how this might have been needed with DEC distributed media, I really can't say. We are using the ka610.bin ROM image that Matt Burke provided when he initially put together the MicroVAX 1 simulator. Maybe the one you have in your personal MicroVAX I and the one he was working with are different. I discarded my personal MicroVAX I as soon as I got my hands on a MicroVAX II processor, so I can't personally check. The MicroVAX I documents on bitsavers.org suggest that [SYSEXE] wouldn't be necessary, but looking for text in the ka610.bin file actually mentions [SYSEXE] and [SYS0.SYSMAINT], but no [SYS0.SYSEXE]. The MicroVAX I boot ROM can't be accessed directly from the console, since it is only references under the covers by the MicroVAX I firmware. You'd have to remove the ROM and read it somewhere...

— Reply to this email directly, view it on GitHub https://github.com/open-simh/simh/issues/215#issuecomment-1529760162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYKR3TPCAH5MTJXYTDGH6DXD7AORANCNFSM6AAAAAAWZ3DWDQ . You are receiving this because you authored the thread.Message ID: @.***>

[markpizz]

No new issue, but provide the images that fail.

I thought I remembered you actually had a MicroVAX I. Do you still have one? It may no longer work (for power supply or other reasons), but extracting ROM contents should still be possible. Those ROM devices were socketed....

[vaxorcist]

I sent the two MicroVMS V4.0 Standalone Backup RX50 images with my last email. Now you get the MicroVMS V4.0 RD52 image with exactly the same symptoms. You'll get the ROM image tomorrow. Thanks for your help!

Ulli

Am Mo., 1. Mai 2023 um 20:01 Uhr schrieb Mark Pizzolato < @.***>:

No new issue, but provide the images that fail.

I thought I remembered you actually had a MicroVAX I. Do you still have one? It may no longer work (for power supply or other reasons), but extracting ROM contents should still be possible. Those ROM devices were socketed....

— Reply to this email directly, view it on GitHub https://github.com/open-simh/simh/issues/215#issuecomment-1530019873, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYKR3XYURKSFCH2JQXLMATXD73A3ANCNFSM6AAAAAAWZ3DWDQ . You are receiving this because you authored the thread.Message ID: @.***>

[markpizz]

Attachments to email messages don't get added to the issue. You've got to drop a zip file while composing additional comments to the issue in a web browser...

[vaxorcist]

uVMS040.R52.zip STABA040.zip Here are the images you asked for. Sorry for the delay!

[vaxorcist]

Here are two MicroVAX I ROM images, of which one is from my machine, the other one from a friend's; unfortunately I cannot remember which is which. MVI-ROMs.zip

[microvax2]

Very likely related to this issue so did not want to start a new one. Issue: VAX/VMS (4.6, 4.7, 5.4) disk images created using SIMH boot fine on SIMH, but do not boot on a real MicroVAX I. Error message:

>>>B DUA0
ATTEMPTING BOOTSTRAP

%BOOT-F-ERROR, Program image not found DUA0
000008B3 02

Apparently there are at least three (3) ROM versions on KD32-AA CPU boards. The one I have (the mentioned M7135_MicroVAX_I_2764_E78.bin) does NOT boot from a disk image that was created and working fine on SIMH (using the standard microvax1.exe which I assume was built to use the github file KA610.BIN). The issue is the search path for sysboot.exe, perhaps more but this one is certain:

KA610.BIN:

[SYSEXE]SYSBOOT.EXE
[SYS0.SYSMAINT}DIAGBOOT.EXE

M7135_MicroVAX_I_2764_E78.bin:

[SYS0.SYSEXE]SYSBOOT.EXE
[SYS0.SYSMAINT]DIAGBOOT.EXE

[markpizz]

I've gotten 2 additional MicroVAX I boot ROM images. I haven't gotten around to creating a mechanism to use and alternate ROM image due to various other things at the top of my list.

Thanks for pinging me about this.

[markpizz]

@microvax2 I'm just now re-reading your most recent message:

VAX/VMS (4.6, 4.7, 5.4) disk images created using SIMH boot fine on SIMH, but do not boot on a real MicroVAX I.

This is somewhat backward from the original issue. Specifically, the original issue problem was that the simulator didn't properly boot from some media files (floppy or disks).

Your problem is that a real MicroVAX I doesn't boot from SIMH created media. This raises 2 questions: 1) How did you get the SIMH created disk images accessible to your real MicroVAX I? How did the disk images get to real physical media? 2) To help address this it will be most useful to know what ROM your real MicoVAX I has in it. There might be labeling on the ROM chip(s) indicating something we could correspond to one of the ROM images we've already got. That would be greatt. Otherwise, please see if you can remove the ROM chip(s) and read them on some chip reader and send along the what you find.

Thanks

[microvax2]

OK

1. Disk images all created by simh, some RD53 and some are RD54. MicroVMS 4.6 installed using a mounted tape image etc. Then upgraded to VMS 4.7, then to VMS 5.1 and 5.4, again using the standard method . Any and all disk images booted fine on simh (microvax1.exe, sometimes had to do that using microvax2.exe because of tape device support issues).
2. simh disk images ported to the real MicroVAX I using two methods. First method: standalone backup kit created by VMS on simh (three floppies) , and VMS used to prepare an image backup of the system disk RD53 to 30 floppy disk images. All images transfered to the real machine using a Gotek floppy emulator with an SD card holding them all. Booting standalone backup went fine (for me) from the Gotek, then backup the multiple volume images to a Fujitsu M2261E ESDI drive hooked.up to a Emulex QD21 QBUS ESDI controller. Boot from this drive failed, until sysboot.exe copied.to the "correct" location.

Second Method: transferring a working RD53/RD54 image file from simh to a DREM3 MFM disk emulator hooked up to a RQDX3. Again, will not boot on the real machine, for the same reason. Copying sysboot.exe made it boot fine.

I have two KD32-AA CPU boards and both have this ROM: M7135_MicroVAX_I_2764_E78.bin Sticker on the EPROM reads 129E5.

-Alon.

[markpizz]

Honestly, I'm quite surprised that the drive connected to the Emulex QD21 worked at all. That controller came out well into the MicroVAX II timeframe and the total number of MicroVAX I systems sold were so small that it would have been odd that they even tried to serve the trivial (maybe non-existent) market. The key distinction being that the MicroVAX I did not have a processor based scatter gather map to make memory access simple for DMA operations. The RQDX controllers had added functionality to implement scatter gather for MicroVAX I DMA workable. This "in the controller scatter"gather" would never have been used on any later MicroVAX since all of those systems didn't use Qbus memory. So the Emulex MSCP controllers came along and were tested with newer MicroVAX systems but I'm surprised it worked on the real MicroVAX I.

Getting back to the original problem description and how things must have worked for real systems in the field. Those systems were installed with early MicroVMS media which clearly worked for those systems that were sold with the media DEC provided, Over time, the working systems were upgraded from their original installation in place and given they already had files configured properly for booting, they continued to do so leveraging their original installation components.

When folks come along today, and start from some later setup which possibly was initially configured on a MicroVAX II or MicroVAX 3900, These newer systems and the VMS installation they started from didn't have support for cold installs on the earliest VAX systems (which it seems the MicroVAX I would be classified as). The MicroVAX I was actually the only "earliest VAX" that had a ROM based boot. The rest of the older systems all has some sort of manual steps indicated in the installation or upgrade documentation or external media which was either supplied to boot the newer OSes for a cold install on that particular platform.

You are saying: I have two KD32-AA CPU boards and both have this ROM: M7135_MicroVAX_I_2764_E78.bin Sticker on the EPROM reads 129E5.. The part number for the MicroVAX I CPU is M7135,, and the E78 and 129ES on the ROMs might be the version of the part or possibly a checksum. Since in order for you to boot the media you were messing with, you had to have [SYSEXE]SYSBOOT.EXE properly existing, the ROMs on these system boards would not be the M7135_MicroVAX_I_2764_E78.bin.

I just noticed that the original KA610.bin file in the repo is a 16KB ROM while each of the 2 ROMs that @vaxorcist supplied were 8KB ROMs. The EK-KD32A-TD-002_MicroVAX_I_CPU_Technical_Description_Aug84.pdf file (on page 2-22 mentions that there could be an 8KB or 16KB EPROM. The KA610.bin file is supposed to support the system as either a MicroVAX I or a VAXStation I. The original KA610 ROM image used to work for both cases, it doesn't now.

I fixed the VAXStation I booting case and have also fixed the general boot logic so that it work correctly as long as EITHER [SYSEXE]SYSBOOT.EXE or [SYS0.SYSEXE]SYSBOOT.EXE is available on the disk. This fix won't work for a VAXStation I if the disk being booted doesn't have [SYSEXE]SYSBOOT.EXE present. In that case, you will have to "sim> BOOT /R5=100" and enter [SYS0.SYSEXE]SYSBOOT.EXE at the "Bootfile:" prompt.

On real hardware, if the installed ROM doesn't find the boot file has burned into it, you can boot with:

>>> B/R5=100
or 
>>> B/100

I'm not sure which command works on the MicroVAX I since I no longer have a real one and the simulator's version uses the ROM to boot, but interactions which get to the console prompt (>>>) happen in CPU microcode which isn't part of the simulator.

When one of those commands work, you will get a "Bootfile:" prompt where you can specify the path to the SYSBOOT.EXE file that is actually on the disk.

I'm pretty sure that newer VAX systems had boot logic which looked for both places for SYSBOOT.EXE.

You should be able to build the MicroVAX I from the master branch of the https://github.com/simh/simh repo and the above mentioned fixes should behave as described...

[ethandicks]

On Fri, Jul 7, 2023 at 8:39 PM Mark Pizzolato @.***> wrote:

Honestly, I'm quite surprised that the drive connected to the Emulex QD21 worked at all. That controller came out well into the MicroVAX II timeframe and the total number of MicroVAX I systems sold were so small that it would have been odd that they even tried to serve the trivial (maybe non-existent) market. The key distinction being that the MicroVAX I did not have a processor based scatter gather map to make memory access simple for DMA operations.

True.

The RQDX controllers had added functionality to implement scatter gather for MicroVAX I DMA workable. This "in the controller scatter"gather" would never have been used on any later MicroVAX since all of those systems didn't use Qbus memory.

Also true.

So the Emulex MSCP controllers came along and were tested with newer MicroVAX systems but I'm surprised it worked on the real MicroVAX I.

But - the QD21 does have a controller scatter-gather feature. It's even documented in the manual:

http://www.bitsavers.org/pdf/emulex/QD2151002-J_QD21_Jun90.pdf

===== 8.2.4 Scatter/Gather

The QD21 Disc Controller supports the MicroVAX I I/O technique of scatter-write operations and gather-read operations.

You are saying: I have two KD32-AA CPU boards and both have this ROM: M7135_MicroVAX_I_2764_E78.bin Sticker on the EPROM reads 129E5.. The part number for the MicroVAX I CPU is M7135,, and the E78 and 129ES on the ROMs might be the version of the part or possibly a checksum.

E78 refers to which socket it goes into. 129E5 is probably some sort of version identifier ("nnnAn" is a common pattern seen on various DEC ROMs going back at least as far as the PDP-8)

This is all just for context and clarity. It does seem that there were a couple of incompatible turns along the time the MicroVAX I was a product. We got one in 1984 and I even forget if we loaded MicroVMS 1.0 or MicroVMS 4.0 first. I think we ordered it when MicroVMS 1.0 was the only product available, and very quickly upgraded when newer versions were made available. I still have some original MicroVMS 4.0 and up RX50s but I found one reformatted MicroVMS 1.0 disk in a box that makes me think my fellow engineers had no interest in going backwards at the time and used "obsolete install media" as cheap backup floppies.

I still have that first MicroVAX I. It was put away working but when I went to power it on for a VCF event, the Rifas in the PSU smoked. It's totally repairable but there are other items that are in the repair queue ahead of it. I may be able to more quickly pull the KD32-AA module and check for ROM version information.

-ethan

[vaxorcist]

MicroVMS Standalone Backup V4.0 and MicroVMS 4.0 still hanging after the first message:

$ ./microvax1

MicroVAX I (KA610) simulator V4.0-0 Current git commit id: e499d09f Logging to file "/home/ulli/Neu-Soft ungeprüft/uVMS/uVMS-4.0/UVMS040_001.log" MicroVAX I (KA610) simulator V4.0-0 Current Simulator Framework Capabilities: 64b data 64b addresses Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP Idle/Throttling support is available Virtual Hard Disk (VHD) support RAW disk and CD/DVD ROM support Asynchronous I/O support (Lock free asynchronous event queue) Asynchronous Clock support FrontPanel API Version 15 Host Platform: Compiler: GCC 10.2.1 20210110 Simulator Compiled as C arch: x64 (Release Build) on Jul 9 2023 at 09:11:44 Build Tool: simh-makefile-single-compile Memory Access: Little Endian Memory Pointer Size: 64 bits Large File (>2GB) support SDL Video support: SDL Version 2.0.14, PNG Version 1.6.37, zlib: 1.2.11 PCRE RegEx (Version 8.39 2016-06-14) support for EXPECT commands OS clock resolution: 1ms Time taken by msleep(1): 1ms Ethernet packet info: NAT, TAP, UDP, PCAP: libpcap version 1.9.0-PRE-GIT (with TPACKET_V3) OS: Linux think 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux Processor Name: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz tar tool: tar (GNU tar) 1.34 curl tool: curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3 git commit id: e499d09f git commit time: 2023-07-05T04:07:54-10:00 ./microvax1.ini-15> ATT RQ0 uVMS040.R52 %SIM-INFO: RQ0: 'uVMS040.R52' Contains ODS2 File system %SIM-INFO: RQ0: Volume Name: MICROVMS Format: DECFILE11B Sectors In Volume: 60480 ./microvax1.ini-17> ATT RQ1 STABA040-1.dsk %SIM-INFO: RQ1: 'STABA040-1.dsk' Contains ODS2 File system %SIM-INFO: RQ1: Volume Name: SYSTEM_1 Format: DECFILE11B Sectors In Volume: 800 ./microvax1.ini-19> ATT RQ2 STABA040-2.dsk %SIM-INFO: RQ2: 'STABA040-2.dsk' Contains ODS2 File system %SIM-INFO: RQ2: Volume Name: BACKUP Format: DECFILE11B Sectors In Volume: 800 sim> B RQ0 %SIM-INFO: Loading boot code from internal ka610.bin .2..1..0.

MicroVMS Version V4.0 15-SEP-1984 22:29

Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim> c

Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim> c

Simulation stopped, PC: 80008B1F (BRB 80008B1F) sim>

even when using the MicroVAX I from the master branch of the https://github.com/simh/simh repo.

Remember, the Standalone Backup images I use are made from genuine DEC RX50 media, and the MicroVMS 4.0 disk image was made with a Standalone Backup from a newer MicroVMS version, again from images from genuine DEC RX50 media. All RX50 images are tested to be free from errors.

[markpizz]

I see the problem. It seems that something about the MSCP controller isn't behaving as expected in this ancient version of VMS.

The boot logic doesn't care and, that we see "MicroVMS Version V4.0 15-SEP-1984 22:29" means the basic VMS functionality has been loaded. The VMS MSCP controller initialization sequence happens repeatedly, but for some reason, that version of VMS doesn't like something about what it gets back.

If we had fiche listings from this version of VMS we could see exactly what it is looking for.. That system shipped with a RQDX1 and the logic in the RQ device implements various MSCP controllers defaulting to RQDX3, but has no specific knowledge about parameters and behaviors for RQDX1 and the RQDX2.

Later VMS versions all existed when the RQDX3 had been released, so the VMS driver initialization code is happy about what is is seeing...

[markpizz]

If you really want to see the MicroVMS from your RD52 image running on the MicroVAX I simulator, you could probably first boot a newer VAX simulator with that RD52 disk image attached to RQ3 and an empty RL02 setup on RL0 and boot from a newer VMS version. Once that newer VMS version is running:

   $ MOUN/OVER=ID DUA3
   $ MOUNT/FOR DLA0:
   $ BACKUP/IMAGE DUA3: DLA0:

Then comes the hard part, which is getting the MicroVAX I simulator to boot from the RL02. The BOOT ROM doesn't support direct booting from anything but a MSCP attached device, but I vaguely recall a sort of indirect VMS boot that could be done on this system. That might have involved creating a floppy that merely had a single file on it called [SYSEXE]SYSBOOT.EXE, but the SYSBOOT.EXE wasn't really the VMS SYSBOOT.EXE, but instead was a copy of VMB.EXE which knew about both booting from RL devices AND knew something about the MicroVAX I CPU. I don't know where such a VMB could be found. I just tried using the VMB.EXE from VMS 5.5-2 and it didn't know about the MicroVAX I processor. :-(

[pkoning2]

MSCP controllers are all pretty similar, they are supposed to all follow the same rules. But of course we know that multiple implementations of the same architecture, nominally equivalent, in practice often are not. So the challenge here seems to be to find out why our RQDX1 emulation isn't good enough for VMS to be happy with it.

[markpizz]

The RQ device DOES NOT simulate an RQDX1, but a RQDX3. Something in the earliest VMS version driver initialization logic seems to be looking for something specifically provided by the RQDX1. Newer VMS versions work just fine on this MicroVAX I simulator.

[pkoning2]

If the software was done right, it wouldn't matter what it emulates so long as it obeys MSCP. But from what we see here it does appear to matter, so my point is that the RQ device emulation should be extended to emulate the bugs of the various MSCP controllers, at least well enough that software works with them. I wouldn't go so far as to say that RQ should emulate bad block replacement as it existed with some early devices, because we wouldn't trigger any of that logic. But the "happy path" cases ought to work. The guiding principle of SIMH is to emulate not just the specs but also enough of the bugs for code to work with the emulation.

[markpizz]

I'm not disagreeing with you. As stated before, the MSCP controller emulated identifies as a RQDX3. This controller was not available when the VMS versions that aren't working were released. These VMS versions only knew about RQDX1/RQDX2. Later VMS versions knew about the RQDX3 and therefore didn't have problems on the MicroVAX I simulator.

I've changed the current RQ device implementation in https://github.com/simh/simh master branch to optionally identify as an RQDX1 and changed the default to be RQDX1 in the MicroVAX I simulator.

The failing MicroVMS 4.0 version now works as expected.

[agn453]

Are issues reported to Open-SIMH only being remedied in the "other" repository now?

[markpizz]

Most of the issues that I personally address, along with my new development and enhancements, are being done in https://github.com/simh/simh master branch.

Issues can be remedied by anyone.

[vaxorcist]

Is it possible that there is something left over from testing in the latest microvax1 sources?

I get:

• ...*

• $ set ter/dev=VT100 $ sh sysVAX/VMSsim> NOEXPECT "Bootfile:"sim> NOEXPECT "%BOOT-F-ERROR, Program image not found DUA"sim> NOEXPECT "%BOOT-F-ERROR, None of the bootable devices contain a program image"sim> NOEXPECT "%BOOT-F-ERROR, Boot device I/O error XQA"sim> NOEXPECT "%BOOT-F-ERROR, No response from load server XQA"sim> CONTINUE V4.0 on node 10-JUL-2023 08:08:20.87 Uptime 0 00:02:30 Pid Process Name State Pri I/O CPU Page flts Ph.Mem00000010 NULL COM 0 0 0 00:01:56.62 0 0 00000011 SWAPPER HIB 16 0 0 00:00:00.30 0 0 00000014 JOB_CONTROL HIB 8 17 0 00:00:00.39 83 185 00000015 SYSTEM CUR 4 125 0 00:00:04.66 591 198 $ sh mem*

• ...*

without any EXPECT in my ini file when running MicroVMS V4.0.

Thanks a lot for fixing the microvax1 simulator to run MicroVMS V4.0! Now I know I have to find an RQDX1 controller if I want to run MicroVMS V4.0 on my real MicroVAX I.

Ulli

Am Mo., 10. Juli 2023 um 04:14 Uhr schrieb Mark Pizzolato < @.***>:

Most of the issues that I personally address, along with my new development and enhancements, are being done in https://github.com/simh/simh master branch.

Issues can be remedied by anyone.

— Reply to this email directly, view it on GitHub https://github.com/open-simh/simh/issues/215#issuecomment-1627971518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYKR3QZ4NM3X6MWRFFH7HLXPNQPFANCNFSM6AAAAAAWZ3DWDQ . You are receiving this because you were mentioned.Message ID: @.***>

[agn453]

@markpizz The license to the simh/simh repository specifically excludes the use of any of your personally authored code after your petty change of licensing over autosize and metadata in disk images resulted in the setting up of Open-SIMH. Are you saying “anyone” can port your remedies into Open-SIMH?

[markpizz]

Thanks a lot for fixing the microvax1 simulator to run MicroVMS V4.0! Now I know I have to find an RQDX1 controller if I want to run MicroVMS V4.0 on my real MicroVAX I.

Actually, an RQDX1 or RQDX2 would do as well.

As for the rest of what you've said here, I can't see what's happening since you've replied via email.

Will you please take what you're reporting and enter it directly as a comment in this issue and place what you're captured between 2 sets of three ` characters. Review it with the "Preview tab" before hitting the Comment button.

Thanks.

It might also be useful if you put the contents of your ini file between 2 sets of three ` characters as well.

[markpizz]

I am saying that NO ONE can port any of my changes which are uniquely in simh/simh to open-simh.

Anyone can readily use exactly what is in simh/simh unmodified.

[vaxorcist]

I get something strange in my console log file, without any EXPECT in my ini file when running MicroVMS V4.0:

 ...
 $ set ter/dev=VT100          
 $ sh sys

VAX/VMSsim> NOEXPECT "Bootfile:"
sim> NOEXPECT "%BOOT-F-ERROR, Program image not found DUA"
sim> NOEXPECT "%BOOT-F-ERROR, None of the bootable devices contain a program image"
sim> NOEXPECT "%BOOT-F-ERROR, Boot device I/O error XQA"
sim> NOEXPECT "%BOOT-F-ERROR, No response from load server XQA"
sim> CONTINUE
 V4.0  on node  10-JUL-2023 08:08:20.87   Uptime    0 00:02:30
  Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
00000010 NULL            COM      0        0   0 00:01:56.62         0      0  
00000011 SWAPPER         HIB     16        0   0 00:00:00.30         0      0  
00000014 JOB_CONTROL     HIB      8       17   0 00:00:00.39        83    185  
00000015 SYSTEM          CUR      4      125   0 00:00:04.66       591    198  

 $ sh mem
 ...

I use the following ini file:

SET CONSOLE LOG=UVMS040_002.log

SET CPU HISTORY=100

SET THROTTLE 300K
DEP QTIME 300
DEP XTIME 300

SET CPU 2M
SET RQ0 RD52
ATT RQ0 uVMS040.R52
SET RQ1 RX50
ATT RQ1 STABA040-1.dsk
SET RQ2 RX50
ATT RQ2 STABA040-2.dsk
SET RQ3 DISABLE

SET DZ DISABLE
SET LPT DIS
SET RL DIS

SET XQ DIS

BOOT RQ0

Ulli

[vaxorcist]

... hit the wrong button, sorry ...

[markpizz]

Try now.

[vaxorcist]

Perfect!

But:

MicroVAX I simulator boots from oldest MicroVMS media due to the addition of RQDX1 disk controller type.

is not true - there was MicroVMS V1.0 which preceeded MicroVMS V4.0. The simulator will probably work with MicroVMS V1.0, too, but we don't know for sure.

MicroVMS V1.0 hasn't been unearthed yet, but you never know ...

Thanks again!

Ulli

[markpizz]

Since MicroVMS V1.0 most likely predated MicroVMS v4.0, and the MicroVAX I was only sold with RQDX1 or possibly RQDX2 controllers, and there was no software detectable difference between the RQDX1 and RQDX2, since it works now, it will most likely work with MicroVMS V1.0.

I'm sure you will come back and report if it doesn't work when you happen to find it. :-)

[vaxorcist]

You are most probably right. And of course I will come back if not. :-))