There were really some major errors in my code proccessing the command "get unit status" with the modfiier bit "md_nxu" set. RSTS/E is a first using this bit, actually surprising as it allows you to detect how many disks are attached to the MSCP controller and how many units are potentially supported. This explains why the error did go unnoticed. So I straightened this and now the output from the trace in simh and the output of the logging produced by my MSCP controller are identical but only to a certain point. The boot process will eventually reach a point where it scans the MSCP controller for all units after having checked other hardware, the memory, etc. From this point on the boot process using simh RSTS/E will initialize the MSCP controller and set new parameters. Something very common during the boot process. But in my test system RSTS/E does not initialize the MSCP controller, i.e. it does not perform a write to the IP register and then continue with the initialisation process. It just reads the IP register which triggers a POLL and apparently the parameters for DMA are no longer valid. I attached the LA to the Q-Bus and indeed after the last get unit status there is no DATO to the IOPage, just a DATI to the SA register to check for errors and then a DATI to the IP. But why is it different? My MSCP controller cannot detect this situation as there is no DATO to the IP on the Q-Bus. So either one of the reads before failed without noticing, writing bad values perhaps? Or is it a problem with my system. Except for my MSCP controller the system consists only of genuine Q-Bus cards, a M8192, a DLV11J and 1Mbyte Card CI-1123+ from Chrislin. How picky is RSTS/E? Any suggestions what I should check?
