The KS10 doesn't support the RK disks. This communication may not represent my employer's views, if any, on the matters discussed.
On 27-May-13 09:32, Robert Jarratt wrote:
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 theyaretrying 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 problemYou must be the first user of these routines...Actually he is not. The only other current user is in the pdp11_cr(CD11simulation).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 bitisnever 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
