Skip to content

Conversation

@markpizz
Copy link
Contributor

@markpizz markpizz commented Dec 8, 2025

If a simh DEVICE has the DEV_DISABLE flag set AND it has 1 UNIT, there really should never be a UNIT_DISABLE flag bit in the UNIT initializer. The reason for this is that, for many things, the DEVICE name can be used equivalently to represent the single UNIT. What are we trying to achieve here?

  • If the DEVICE is disabled, then the unit doesn't exist. That's fine.

  • If the UNIT is disabled (if the UNIT_DISABLE flag is present allowing SET DISABLE) what would that then mean about the DEVICE?

Bob Supnik's thoughts:

The rationale was that the device represents the controller logic, the unit the physical transducer. So you could disconnect or power down a paper tape reader, but its controller logic would still be there and would still respond in some way.

Mark Pizzolato said:
If the fidelity to the hardware in simulation really behaved precisely as the hardware worked, maybe, but I doubt that this has been a design goal. Even if it had been a design goal, I see 2 issues:
a) it would seem that it would have been impossible to produce exactly
the failure details that real hardware did without a crazy amount
of side by side testing.
b) What good would be having a broken device like this connected to a
simulated system?

…ABLE

If a simh DEVICE has the DEV_DISABLE flag set AND it has 1 UNIT,
there really should never be a UNIT_DISABLE flag bit in the UNIT
initializer.  The reason for this is that, for many things, the DEVICE
name can be used equivalently to represent the single UNIT.
What are we trying to achieve here?

- If the DEVICE is disabled, then the unit doesn't exist.  That's fine.

- If the UNIT is disabled (if the UNIT_DISABLE flag is present allowing
  SET <unit> DISABLE) what would that then mean about the DEVICE?

Bob Supnik's thoughts:

The rationale was that the device represents the controller logic, the
unit the physical transducer. So you could disconnect or power down
a paper tape reader, but its controller logic would still be there and
would still respond in some way.

Mark Pizzolato said:
If the fidelity to the hardware in simulation really behaved precisely
as the hardware worked, maybe, but I doubt that this has been a design
goal.  Even if it had been a design goal, I see 2 issues:
   a) it would seem that it would have been impossible to produce exactly
      the failure details that real hardware did without a crazy amount
      of side by side testing.
   b) What good would be having a broken device like this connected to a
      simulated system?
@rcornwell
Copy link
Owner

I'm going to reject this patch since it does not serve any purpose.

@markpizz
Copy link
Contributor Author

markpizz commented Dec 9, 2025

It removes the option to day "SET DISABLE" for devices which have a single UNIT.

  • Please explain how such a device would be useful with it's single unit disabled?
  • Please precisely how the simulated system will know this in a way that it did on real hardware?

Certainly, DEVICEs with multiple UNITs could still be useful if some of their UNITs are non-existant, but otherwise, how will you be able to tell precisely how the running simulated system would be able to see exactly what the original hardware saw when the single UNIT is disabled?

B5500 simulator Open SIMH V4.1-0 Current        git commit id: 4d383732
sim> help cp set

CP device SET commands:

set CP FORMAT                   Sets card format
set CP ENABLE                   Enables device CP
set CP DISABLE                  Disables device CP
set CP DEBUG                    Enables debugging for device CP
set CP NODEBUG                  Disables debugging for device CP
set CP DEBUG=CMD;DATA;DETAIL;EXP;CARD
                                Enables specific debugging for device CP
set CP NODEBUG=CMD;DATA;DETAIL;EXP;CARD
                                Disables specific debugging for device CP
set CP ENABLE                   Enables unit CP
set CP DISABLE                  Disables unit CP
set CP APPEND                   Sets CP position to EOF

*CP device DEBUG settings:
    CMD         Show command execution to devices
    DATA        Show data transfers
    DETAIL      Show details about device
    EXP         Show console data
    CARD        Show Card read/punches

Notice the duplicate SET CP ENABLE SET CP DISABLE options.

@markpizz
Copy link
Contributor Author

markpizz commented Dec 9, 2025

I don't care who's name is on the commit, but I think it is a good idea to remove the potential ambiguity in the example I showed. Precisely the same issue exists for every other device that has this trivial change in the PR.

@rcornwell
Copy link
Owner

Right now I am knee deep in microsim360. Trying to get reference IBM360 so I can finish my simH IBM360.

I still see this patch as cosmetic.

@markpizz
Copy link
Contributor Author

markpizz commented Dec 9, 2025

It absolutely is cosmetic, and was a result of a complaint about the cosmetic information provided by the HELP output, which, at best, wasn't consistent and the multiple cases were confusing and didn't have the expected information for the user. Such information should be correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants