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

[Timothe Litt]

This thread is getting far too messy.

The increment problem found by Rob is NOT subtle.  It's just plain broken.

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

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/de3da3ad/attachment-0002.bin>