[Simh] Software, firmware, and friends

[Timothe Litt]

On 16-Mar-17 15:02, Seth Morabito wrote:

> [I seem to have missed the original message from Bob, so replying
> via Johnny's message.]
>
> On 2017-03-12 22:51, Bob Supnik wrote:
>> In general, I am no longer a fan of "approximate" simulations. If you
>> just use the spec and ignore the implementation, then even if some
>> particular test case (VMS Vxyz) works, the next piece of software may
>> fail. I've seen this repeatedly - how the initial simulation of the RH
>> worked with all DEC operating systems but failed with Unix, because a
>> critical screw-up in the interrupt logic wasn't implemented faithfully;
>> how the 750 simulation ran VMS but failed with BSD, because the UBA was
>> a simple clone of the 780 (it's still wrong in critical aspects, as is
>> the RH750); how the MicroVAX II & III/QVSS combo failed with Ultrix,
>> because Ultrix cheerfully violates the SRM and the hardware just works.
>> I'm still trying to work out the mischief that the SDS 940's tape drive
>> perpetrates. The devil is in the details.
> This has plagued me continuously while trying (and often failing) to get
> the 3B2 simulator working. The lack of documentation from AT&T means I
> have had to get at everything via reverse engineering, and that means
> that sometimes I must make educated guesses, and sometimes those guesses
> are wrong. And other times, even when looking at the real hardware under
> a logica analyzer, I may misunderstand what I'm seeing, or make wrong
> assumptions about what I'm seeing. It is very frustrating, and slow, and
> painful.
>
> I'm facing a situation now where I believe I am very faithfully
> following the microsequences _as described_ in the WE32100 manual, but I
> am seeing results that lead me to believe the manual is incorrect, or
> more likely incomplete. 

Or was correct and complete at the time, but not updated (or you don't
have the update) for a subsequent engineering change (hardware or
firmware revision).  Or doesn't describe customer-specific modifications
(some of which spread without a formal engineering change).

Or correctly and completely described the design, but a bug was too
expensive or inconvenient to fix, so software adapted to the broken
behavior.  And the documentation wasn't changed, or you don't have the
update.

Or interaction with some other aspect of the system causes behavior
that, once you understand it is clearly documented; but by no means
obvious from reading one document alone.

Many engineering documents of the era described things in detail the way
engineers think; boxes and interfaces.  Documentation for systems
composed of those components often uses abstractions suitable for the
intended reader, but that gloss over implementation detail necessary for
simulators.

Bob has written papers on some of the adventures creating simh; I went
on a number of treasure hunts so we could determine how things really
worked...

Things are rarely as simple as they seem.
> (The manual, after all, is targeted at people
> trying to write software for the WE32100, not people trying to
> implement it, so I can't really blame the authors)
>
> So, I agree completely. The 3B2 simulator is unfortunately an approximate
> simulation, rather than fully faithful to the original. And I am
> unlikely to ever know HOW approximate it is!
>
> -Seth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170316/d4b7e33e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170316/d4b7e33e/attachment.bin>