SimH scmd files fail on current 4.* version; only 3.* supported

[wfjm]

SimH scmd files fail on current 4.* version; only 3.* supported

[wfjm]

The maintainer of the simh/simh GitHub project, Mark Pizzolato, decided on May 15th, 2022 with commit ce2adce6 to change the license of the repository. The bottom line of the change is, that some files are declared proprietary and this repository is not longer a FOSS project, see also issue #1163.

This triggered massive reactions, see issue #1161 and discussions on the
SimH mailing list [email protected], starting with post 91108560.

Bottom line is that this w11 issue is put on hold until the overall SimH project situation is resolved.

[wfjm]

The license change of simh/simh triggered a fork of a new project open-simh/simh under an MIT style license and a team of maintainers. See

• announcement from Paul Koning
• description description from Jon Brase

The momentum of the SimH development will certainly move to open-simh.
w11 will stay with 3.x "classic" simh until the 4.x development is re-focused in open-simh.

[markpizz]

You mention the following detailed messages you recieved:

• Device auto configuration is now disabled

You are now merely getting a message which describes the behavior that has always existed in ALL prior simh versions, but not necessarily been verbosely reported. The lack of not reporting produced confusion for various folks. You might want to heed the info in the message, but if it isn't relevant to you, you could change the command which causes it to be emitted to:

set -q dz vector=310

the -q will have no effect on earlier simh versions and will cause these possibly non-informative messages to be suppressed.

You need not explicitly set the vector in your scmd file since when the simulator starts using your configuration file, the DZ device will start with a vector of 310. Explicitly setting it is redundant and has the side effect of disabling autoconfigure and when that happens on the earlier v4 you get the message telling you that.

• Command not allowed (for set rha enabled)

This command does indeed fail. The reason it fails is due to the fact that in the v4 codebase, the RH devices are automatically associated with the appropriate massbus device that may need to use it. Enabling RP connects that device to RHA, enabling TU connects it to the first available massbus (if RP is not enabled, then TU ends up on RHA).
The 'set rha enabled' command is completely unneeded since on all older versions of simh they all start with RHA enabled, so enabling the already enabled device has no effect.

• container incompatible with the RL device

Testing with the latest code in the FOSS version and I did not initially see a failure with a message like this.

I did see a failure with the SIGSEGV you mention earlier. Had you ever reported this as a problem in the github.com/simh/simh issue system any time in the last 6 years it would have been fixed to at least avoid the SIGSEGV. The problem here derives from your earlier "set dz vector=310" command AND the order of the commands in your configuration file. Disabling autoconfigure (by explicitly setting a vector on the DZ device), causes the XU device to not have an address or vector which normally would be assigned by autoconfigure. The disabling of autoconfigure when explicitly setting an ADDRESS or VECTOR has been around way back in the v3 timeframe. Things might have not caused a problem in the past due to many/most devices not actually being configured by autoconfigure. Having autoconfigure setup everything allows for truly arbitrary configurations to work. Once again this issue can be avoided by not setting the vector for the DZ device, or at least enabling the XU device before setting the DZ devices vector. A configuration which follows these rules will work with v4 and v3 versions.

Getting back to the container incompatible subject, there is some potential for this to happen under certain circumstances, but in your use, it seems you might be using the container's contents outside of simh. If that is so, then you might explicitly desire that the container not have anything but the raw disk contents. You can have the latest simh v4 (open-simh/simh or simh/simh) avoid adding container metadata to disk container files if you have a file in your home directory called simh.ini which contains a "SET NOAUTOSIZE" command.

Looking closer at this detail, the v4 behavior is actually reasonable. You might wonder why. The container you're using is a RL02 container with a RT11 file structure on it. That RT11 file structure has a single partition which would actually fit on a RL01 with the rest of the container unallocated. Nowhere in your scmd files do you actually set the drive type of the RL0 unit to be RL02. On both simh v3 and v4 the RL0 unit starts as a RL01 drive type and when you attach and use that container on v3 it works normally since the size of the useful data area on the drive would fit on a RL01. v4 autosizes the drive type based on the container size and thus it automatically changes the drive type. It is just a coincidence that this worked for you on v3 simh versions.

As you stated in the subject of this issue, all of these issues absolutely occur in the v4 codebase, and they silently occurred in the v3 codebase as well but sort of managed to work. You can make changes to your scmd files so that they behave correctly on all simh versions.

As a result of the feedback you mentioned here, the going forward v4 codebase at github.com/simh/simh has been revised to include at least the following changes:
1 - avoid SIGSEGV in PDP11 and VAX devices and actively report when the address and vector values are unreasonable before actually initiating simulator instruction execution,
2 - relax the SET ADDRESS= and VECTOR= logic such that if the set value doesn't change what was previously configured, then autoconfigure is not disabled, with more explicit reporting of invalid arguments in both ADDRESS and VECTOR.
3 - polish on the disk logic to better explain what's happening and repair potentially incorrectly stored metadata.

According to the non FOSS license in the github.com/simh/simh master branch, you and everyone else are absolutely free to use the latest code in the github.com/simh/simh master branch AS LONG AS you don't explicitly need to change the behavior of the disk sizing logic. If you have or observe problems with any of this logic, please report the problems or ask questions in the github.com/simh/simh/issues system and they will be addressed. These and other changes made by me are NOT part of the FOSS open-simh repo.

[wfjm]

@markpizz : thanks for the analysis. I've reviewed and updated the .scmd files, which were in many cases created 12+ years ago for v3.8. The SimH setup now fully relies on autoconfiguration, and that matches the current w11 hardware implementation. The RL and RP disk types are now always explicitly set. For the time being I'll use SimH "Classic". When the meta-data issue is cleaned up (see open-simh/simh#13) I'll re-consider open-simh/simh. And I'll not look into simh/simh anymore for obvious reasons (see simh/simh#1163).

[wfjm]

Cleanup for V3.* done with 35453c4.
Close issue for now, labeled 'suspended'.
Maybe reactivated when V4.* status evolves.