<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>On 16-Mar-17 15:02, Seth Morabito wrote:<br>
</p>
<blockquote cite="mid:20170316190242.GA3456@loomcom.com" type="cite">
<pre wrap="">[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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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. </pre>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
Things are rarely as simple as they seem.<br>
<blockquote cite="mid:20170316190242.GA3456@loomcom.com" type="cite">
<pre wrap="">(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
</pre>
</blockquote>
<br>
</body>
</html>