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

[Robert Jarratt]

I also see a reference in pdp11_hk which is the RK611/RK06/RK07 disk
controller

Regards

Rob

> -----Original Message-----
> From: Timothe Litt [mailto:litt at ieee.org]
> Sent: 27 May 2013 13:50
> To: Mark Pizzolato - Info Comm
> Cc: Robert Jarratt; simh at trailing-edge.com
> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code?
> 
> It is a subtle bug having to do with what happens to bits that nominally
> don't carry useful data.
> 
> Most -10 code wouldn't notice since <17:16> would be ignored.  it would
> just fetch the expected data with a load byte instruction.
> 
> TOPS-20 is relying on the UBA's clearing of these bits to detect
> hardware or programming errors.
> 
> My suggested changes should not break the CR.
> 
> 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
> >
>