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:[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
