[Info-vax] Kittson question

[terry+googleblog at tmk.com]

On Thursday, January 1, 2015 6:03:48 AM UTC-5, JF Mezei wrote:
> Should a VAX emulator on a new platform really cater to such hacks ?

Probably. Even where the result of a specific operation is "undefined" in the architecture, an emulator should faithfully reproduce the behavior of the existing system, in case something (operating system or application) running on the actual hardware either inadvertently or intentionally depends on the behavior.

Most of the intentional cases are probably early in operating system initialization, where this is used to detect what hardware the operating system is running on and configure things appropriately. I don't have a lot of experience with non-DEC VAX hardware, but back on the PDP-11 I did a good amount of consulting to develop patches for RSTS/E to change the detection algorithm to configure the operating system appropriately for 3rd-party CPUs.

And, of course, an emulator also needs to emulate the peripherals, including any undocumented behavior. As an example, writing ASCII "MS" to the CSR of many TS11 controllers triggered some magic which caused a load, seek to BOT, and a read of the first tape block to a pre-defined memory location. Most 3rd-party controllers missed this, which caused them to not be usable as boot devices when the bootstrap ROM was on a DEC board. The MXV11-A was the primary offender here - I made modified MXV11-A2 ROMs for an OEM so they could boot from the 3rd-party MS devices they had installed.

Back to VMS - by the time VMS came along, and certainly "modern" VMS (5.0 onward) there was no need for most of these sorts of hacks in order to determine processor model and features. Even so, configuring virtual machines that never existed in the real world will likely lead to unpredictable results (for example, VAXBI on a MicroVAX II). Similarly, on Alpha configuring a newer CPU type (one with byte instructions) on an older system model can lead to problems.