PDP11: RP11: Implement delayed CS_DONE for "initiation" commands (SEEK/HOME)

[al20878]

Running earlier XXDP tests revealed that a technique of concurrent command initiation and continued housekeeping for the command completion was used in the old code.

For example, code could initiate a SEEK command for a drive, and knowing that CS_DONE (and thus, an interrupt) is coming in about 16us, it would then go ahead and clear a flag, which registers that the interrupt has occurred (expected to be set to 1 by the ISR). If CS_DONE is set by the implementation at the function initiation immediately, that would mean that the interrupt could be triggered before the next instruction, and the flag would be set by the ISR right away. The main code, however, would proceed with the the flag clear as the following instruction, thus, never detecting the interrupt down the road.

Since this technique was in existence, it is better to introduce a delay for setting CS_DONE in the "fast" initiation commands like SEEK and HOME, to accommodate the software that was relying on it.

So far, however, no issues were encountered in testing (except one), where this delay mattered, but it's hard to tell if it would not be needed at all.

All I/O commands always delay CS_DONE already because they were never supposed to be immediate.

Since the time for CS_DONE in initiation commands was documented at 16us, the introduced delay is set to 10 instructions, which usually took more than that to execute. But the interrupt flag clear case would be covered, as well as the counted waits, which used some 25+-iteration tight loops for "drive ready", before flagging a time-out (so the delay cannot be longer, either).

It also looks like more modern code never used any such tricks, so for it, it should not matter if CS_DONE was slightly delayed or not.

@pkoning2 : There's also const_assert(), which I think is portable. 0-sized arrays are not, so the dimension has be either positive or negative. Also the condition must be a constant compile-time expression (gcc allows varying size on-stack arrays), so the array has to be static and const, in addition; also, it's better to be initialized, too (in case when assert is valid) -- with, again, a const expression. Lastly, it has to be used (otherwise, the compiler can post a warning), and so it was in the (void) statement.
Could not use static_assert() as it was conflicting with some other stuff in C RTL on Linux, so used the const_assert() name instead.
But I checked, it seems to be working perfectly fine (and actually gcc does not generate any code / storage for it, when the assertion is valid).

[pkoning2]

Merged.