Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

RE: Race in MSCP (ra/rx) driver



On Sunday, August 30, 2020 at 5:52 AM, Mouse wrote:
[...]
> > The simh source has the original ROM image in the VAX/ka630_orig.bin
> > file.  The changes to this (to get the one the simulator uses) are
> > indicated in VAX/ka630_patch.com.  I suspect that if you compare your
> > ROM image to the VAX/ka630_orig.bin, they might actually be the same.
> 
> I had to git pull; my tree was too old to have VAX/ka630_orig.bin.
> But, yes, turns out the _orig file is identical to my image.

It's been in the repo for 4 years.  You should pull more often. :-)

> Looking at the comments in ka630_patch.com, it looks as though I may
> actually have implemented two things simh may not have: console loopback
> and memory parity.  In view of what you said about emulating the hardware
> warts and all, and changing the emulator instead of the emulated code, I find
> this surprising. :-)  Maybe it's just that nobody ever ran into anything but the
> ROM code that cared about console loopback or memory parity?

Well, simh's fundamental goal (for all the approximately 80 simulators) is to 
provide ways for operating systems and applications that ran on those 
operating systems to function in reasonable ways.  An explicit non-goal 
exists to run hardware diagnostics (ROM based or external).  If diagnostics
work, great, if they don't it is not a priority since successful diags isn't 
really required for simulator functionality.  There is no value, for instance,
in emulating parity in the logical memory interface since in simulation there
won't be any such errors and the overhead of continuously managing it 
would seriously impact operational performance for 0 gain.

As for console loopback, I can't say precisely since I didn't write that 
simulator, but the author may have encountered issues early in his 
development (since he started from the MicroVAX 3900 codebase) and
just found it easier to disable since he probably hadn't yet added the 
SET CPU DIAG=FULL flag that only manipulated the single bit in the 
BDR.  Before that he probably was explicitly setting the BDR with a 
DEPOSIT BDR <value> command and he wanted to avoid inadvertently
putting the console into loopback mode which wasn't a particularly 
useful way to run a simulator.

- Mark




Home | Main Index | Thread Index | Old Index