I also see a reference in pdp11_hk which is the RK611/RK06/RK07 disk controller
Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:[email protected]] > Sent: 27 May 2013 13:50 > To: Mark Pizzolato - Info Comm > Cc: Robert Jarratt; [email protected] > 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:[email protected]] > >>>> Sent: 26 May 2013 11:25 > >>>> To: Robert Jarratt > >>>> Cc: [email protected] > >>>> 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 > > > _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
