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

[Timothe Litt]

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
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130527/ab18075b/attachment-0002.bin>