I mean I'm not sure how much I like that theory myself. If you indeed have to select the task width with that jumper in the middle of the board, I don't think we have seen any effort to detect a misconfiguration and an effort to fail gracefully anywhere. Booting SINIX 1.2 on a machine configured for SINIX 1.0 (or vice versa) just fails in super ugly ways, hanging in random looking fault loops or dropping you into the monitor eventually (I think variations of that is what we've seen).
Even in an effort to spare a register for configuration through the OS, they could at least have made the jumpered value readable in software.
But this brings me to one possibility that I don't think is out of the question yet: Recall that the MMU self test uses a task width that is different from both what SINIX 1.0 and SINIX 1.2 use, which makes the whole thing all the more confounding, but also makes it necessary to always set the DIP switch that supposedly indicates whether the MMU is not present in order to skip the otherwise failing MMU self test.
Maybe that DIP switch is not actually indicating presence of the MMU, or just there to skip the MMU self test (since it definitely does not *disable* the MMU). Maybe instead the DIP switches actually configure the MMU, and the self test then just skips the MMU test if the DIP switches do not indicate the right configuration for how the test was written.
If so, it's still weird/unfortunate that SINIX, unlike the MMU self test, does not appear to check the MMU configuration on the DIP switches (though I am not actually 100% sure that SINIX doesn't do that), but I guess it could make slightly more sense?
It's also weird of course that the MMU self test only appears to work in a configuration that does not seem to be valid for either OS version. This all smells like SIEMENS could have changed plans a few times during development.
Last edited by anyfoo; 10/09/20 11:29 PM.