[Simh] TOPS-20 Source with KMC11 Driver Code?

[Mark Pizzolato - Info Comm]

On Monday, May 27, 2013 at 6:19 AM, Timothe Litt wrote:
> This thread is getting far too messy.
> 
> The increment problem found by Rob is NOT subtle.  It's just plain broken.

I agree 100%.  

The code, as written, would write twice as much simulated memory as intended which usually would crash things nicely (and did when Rob tried with the DMC).

I found that the ONLY current use (prior to Rob's DMC) of this routine was in the CD11 simulator and that use either might never actually get executed (if the CDCSR_V_PACK bit not been set), OR if it was actually executed it would have been with the constant byte count of 2 which should have written 1 16/18 bit word, but actually wrote 2 due to the bug.  This may have never been exercised, OR writing the second word may have merely written the high bytes 18 bits of a word which was never referenced by the program...

> The mishandling of the high bits is what I meant when I wrote 'subtle'.

Understood.

> This communication may not represent my employer's views,
> if any, on the matters discussed.
> 
> On 27-May-13 08:37, Mark Pizzolato - Info Comm wrote:
> > On Monday, May 27, 2013, at 5:23 AM Timothe Litt wrote:
> >> On 27-May-13 05:48, Robert Jarratt wrote:
> >>>> -----Original Message-----
> >>>> From: Timothe Litt [mailto:litt at ieee.org]
> >>>> Sent: 26 May 2013 11:25
> >>>> To: Robert Jarratt
> >>>> Cc: simh at trailing-edge.com
> >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code?
> >>>>
> >>>> Rob,
> >>>>
> >>>> Thanks for the log.  Looks like both simh and you have some bugs. But
> >>>> you're close to working...
> >>>>
> >>>> First nit: the KMC CMD & DUP QUEUE debug messaged looks like they
> are
> >>>> trying to print hex as well as octal - missing a % in the printf()
> >>>> format?  (Assuming the data is passed twice...)
> >>> Oops! Missed that, thanks.
> >>>
> >>>> The descriptors look reasonable.
> >>>>
> >>>> Second: The Map_WriteW routine (in pdp10_ksio.c) is preserving bits
> >>>> 0,1,
> >>>> 18 & 19, but this is a 16-bit device.  The real UBA would clear them
> >>>> in this case.  This is a bug in simh.
> >>> Changing ksio from this
> >>>
> >>>       if (ba & 2)
> >>>           M[pa10] = (M[pa10] & INT64_C(0777777600000)) | val;
> >>>       else M[pa10] = (M[pa10] & INT64_C(0600000777777)) | (val << 18);
> >>>
> >>> To this
> >>>
> >>>       if (ba & 2)
> >>>           M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
> >>>       else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
> >>>
> >>> Seemed to cure the immediate problem
> >> You must be the first user of these routines...
> > Actually he is not.  The only other current user is in the pdp11_cr (CD11
> simulation).
> >
> > The use of Map_WriteW in the CD11 is only when the CDCSR bit 1 is set
> (CDCSR_V_PACK) which is a flag controlling 'Data Packing'.  Maybe this bit is
> never set by the PDP10 operating systems, or maybe it is set, but no one
> ever noticed the problem since the transfer size used is always 2 in the
> pdp11_cr code.  Someone should look closer at this, but my knowledge in
> that space is essentially non-existent.
> >
> > - Mark
> >
>