From robert.jarratt at ntlworld.com Tue May 7 18:33:36 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Tue, 7 May 2013 23:33:36 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? Message-ID: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Can anyone point me at the right place to look at TOPS-20 driver code for the KMC11? I can see that it is trying to get the Microprocessor to do something and read back some values, but I don't know what values it wants to get and so it reports: ******************** *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 *KMC11 BROKEN *JOB: 0, USER: OPERATOR *ADDITIONAL DATA: 3760540 ******************** ******************** *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 *KMC11 LOAD FAILED *JOB: 0, USER: OPERATOR ******************** Thanks Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From simh at alderson.users.panix.com Tue May 7 20:01:46 2013 From: simh at alderson.users.panix.com (Rich Alderson) Date: Tue, 7 May 2013 20:01:46 -0400 (EDT) Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> (robert.jarratt@ntlworld.com) References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Message-ID: <20130508000146.A1B69242BE@panix5.panix.com> > From: "Robert Jarratt" > Date: Tue, 7 May 2013 23:33:36 +0100 > Can anyone point me at the right place to look at TOPS-20 driver code for > the KMC11? I can see that it is trying to get the Microprocessor to do > something and read back some values, but I don't know what values it wants > to get and so it reports: Hi, Rob, http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html You want the file KDPSRV.MAC in that directory. Rich From litt at ieee.org Tue May 7 20:07:40 2013 From: litt at ieee.org (Timothe Litt) Date: Tue, 07 May 2013 20:07:40 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Message-ID: <5189974C.3080508@ieee.org> This is a failure loading the KMC microcode. You have to store the bits you get, and allow them to be read back. This communication may not represent my employer's views, if any, on the matters discussed. On 07-May-13 18:33, Robert Jarratt wrote: > > Can anyone point me at the right place to look at TOPS-20 driver code > for the KMC11? I can see that it is trying to get the Microprocessor > to do something and read back some values, but I don't know what > values it wants to get and so it reports: > > ******************** > > *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 > > *KMC11 BROKEN > > *JOB: 0, USER: OPERATOR > > *ADDITIONAL DATA: 3760540 > > ******************** > > ******************** > > *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 > > *KMC11 LOAD FAILED > > *JOB: 0, USER: OPERATOR > > ******************** > > Thanks > > Rob > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Wed May 8 14:10:29 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Wed, 8 May 2013 19:10:29 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? Message-ID: <06ae01ce4c17$5435bdd0$fca13970$@ntlworld.com> Thanks to all those who responded, I now have the info I need. Regards Rob From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] Sent: 07 May 2013 23:34 To: hecnet at update.uu.se; simh at trailing-edge.com Subject: TOPS-20 Source with KMC11 Driver Code? Can anyone point me at the right place to look at TOPS-20 driver code for the KMC11? I can see that it is trying to get the Microprocessor to do something and read back some values, but I don't know what values it wants to get and so it reports: ******************** *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 *KMC11 BROKEN *JOB: 0, USER: OPERATOR *ADDITIONAL DATA: 3760540 ******************** ******************** *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 *KMC11 LOAD FAILED *JOB: 0, USER: OPERATOR ******************** Thanks Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.jarratt at ntlworld.com Wed May 8 17:29:53 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Wed, 8 May 2013 22:29:53 +0100 Subject: [Simh] TOPS20 4.1 DECnet Progress Message-ID: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Making progress: $OPR OPR>ENTER NCP NCP>SHOW STATUS KNOWN LINES NCP> 22:25:11 NCP request # 2 [SHOW STATUS KNOWN LINES] Status as of 8-May-2013 22:25:12 Line ID State Adjacent Node KDP_0_0 On KDP_0_1 On Function completed successfully NCP> J Regards Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 10 02:28:07 2013 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 10 May 2013 06:28:07 -0000 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Message-ID: On Wed, 8 May 2013, Robert Jarratt wrote: > > Making progress: > > ? > > $OPR > > OPR>ENTER NCP > > NCP>SHOW STATUS KNOWN LINES > > NCP> > > 22:25:11????????? NCP request # 2 [SHOW STATUS KNOWN LINES] > > ? > > ??????? Status as of 8-May-2013 22:25:12 > > ? > > ??????? Line ID???????? State?????????? Adjacent Node > > ? > > ??????? KDP_0_0???????? On > > ??????? KDP_0_1???????? On > > ????????? Function completed successfully > > NCP> > > ? > > J > > ? > > Regards > > ? > > Rob > > > I wonder if it would be possible to apply what you've done with TOPS-20 to TOPS-10. -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From robert.jarratt at ntlworld.com Fri May 10 13:25:39 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Fri, 10 May 2013 18:25:39 +0100 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress In-Reply-To: References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Message-ID: <082101ce4da3$65a76400$30f62c00$@ntlworld.com> > -----Original Message----- > From: Cory Smelosky [mailto:b4 at gewt.net] > Sent: 10 May 2013 07:28 > To: Robert Jarratt > Cc: simh; hecnet > Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress > > On Wed, 8 May 2013, Robert Jarratt wrote: > > > > > Making progress: > > > > > > > > $OPR > > > > OPR>ENTER NCP > > > > NCP>SHOW STATUS KNOWN LINES > > > > NCP> > > > > 22:25:11????????? NCP request # 2 [SHOW STATUS KNOWN LINES] > > > > > > > > ??????? Status as of 8-May-2013 22:25:12 > > > > > > > > ??????? Line ID???????? State?????????? Adjacent Node > > > > > > > > ??????? KDP_0_0???????? On > > > > ??????? KDP_0_1???????? On > > > > ????????? Function completed successfully > > > > NCP> > > > > > > > > J > > > > > > > > Regards > > > > > > > > Rob > > > > > > > > I wonder if it would be possible to apply what you've done with TOPS-20 to > TOPS-10. > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to install DECnet on TOPS-10 have not gone well so far though, it fails to link after MONGEN. Regards Rob From b4 at gewt.net Fri May 10 13:29:00 2013 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 10 May 2013 17:29:00 -0000 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> <082101ce4da3$65a76400$30f62c00$@ntlworld.com> Message-ID: On Fri, 10 May 2013, Robert Jarratt wrote: > > > >> -----Original Message----- >> From: Cory Smelosky [mailto:b4 at gewt.net] >> Sent: 10 May 2013 07:28 >> To: Robert Jarratt >> Cc: simh; hecnet >> Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress >> >> On Wed, 8 May 2013, Robert Jarratt wrote: >> >>> >>> Making progress: >>> >>> >>> >>> $OPR >>> >>> OPR>ENTER NCP >>> >>> NCP>SHOW STATUS KNOWN LINES >>> >>> NCP> >>> >>> 22:25:11????????? NCP request # 2 [SHOW STATUS KNOWN LINES] >>> >>> >>> >>> ??????? Status as of 8-May-2013 22:25:12 >>> >>> >>> >>> ??????? Line ID???????? State?????????? Adjacent Node >>> >>> >>> >>> ??????? KDP_0_0???????? On >>> >>> ??????? KDP_0_1???????? On >>> >>> ????????? Function completed successfully >>> >>> NCP> >>> >>> >>> >>> J >>> >>> >>> >>> Regards >>> >>> >>> >>> Rob >>> >>> >>> >> >> I wonder if it would be possible to apply what you've done with TOPS-20 to >> TOPS-10. >> > > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to > install DECnet on TOPS-10 have not gone well so far though, it fails to link > after MONGEN. > That was the same problem I was having. > Regards > > Rob > > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From litt at ieee.org Fri May 10 13:39:26 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 10 May 2013 13:39:26 -0400 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress In-Reply-To: <082101ce4da3$65a76400$30f62c00$@ntlworld.com> References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> <082101ce4da3$65a76400$30f62c00$@ntlworld.com> Message-ID: <518D30CE.2000707@ieee.org> On 10-May-13 13:25, Robert Jarratt wrote: > >> -----Original Message----- >> From: Cory Smelosky [mailto:b4 at gewt.net] >> Sent: 10 May 2013 07:28 >> To: Robert Jarratt >> Cc: simh; hecnet >> Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress >> >> On Wed, 8 May 2013, Robert Jarratt wrote: >> >>> Making progress: >>> >>> >>> >>> $OPR >>> >>> OPR>ENTER NCP >>> >>> NCP>SHOW STATUS KNOWN LINES >>> >>> NCP> >>> >>> 22:25:11 NCP request # 2 [SHOW STATUS KNOWN LINES] >>> >>> >>> >>> Status as of 8-May-2013 22:25:12 >>> >>> >>> >>> Line ID State Adjacent Node >>> >>> >>> >>> KDP_0_0 On >>> >>> KDP_0_1 On >>> >>> Function completed successfully >>> >>> NCP> >>> >>> >>> >>> J >>> >>> >>> >>> Regards >>> >>> >>> >>> Rob >>> >>> >>> >> I wonder if it would be possible to apply what you've done with TOPS-20 to >> TOPS-10. >> > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to > install DECnet on TOPS-10 have not gone well so far though, it fails to link > after MONGEN. > > Regards > > Rob Assuming you follow the installation guide and that there's no version skew, any version of TOPS-10 that supports DECnet should build and run out of the box. If you provide the specific version & tape images, commands used and all output, we can advise. Do note that if you are using any unsupported/customer supported modules (e.g. the DMR driver), they need to be obtained from the 'customer supported' tape/directory and added to the build files. This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 04:53:53 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 09:53:53 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <20130508000146.A1B69242BE@panix5.panix.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> Message-ID: <030e01ce546e$67754f00$365fed00$@ntlworld.com> > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Rich Alderson > Sent: 08 May 2013 01:02 > To: hecnet at update.uu.se; simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > From: "Robert Jarratt" > > Date: Tue, 7 May 2013 23:33:36 +0100 > > > Can anyone point me at the right place to look at TOPS-20 driver code > > for the KMC11? I can see that it is trying to get the Microprocessor > > to do something and read back some values, but I don't know what > > values it wants to get and so it reports: > > Hi, Rob, > > http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html > > You want the file KDPSRV.MAC in that directory. > > Rich > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh I am making some progress with getting the KMC/DUP emulation working in SIMH for TOPS-20. At the moment I am stuck on one thing, which is the interrupts to tell the OS that the KMC has processed a buffer. The OS sets the interrupt enable bit and when I have something to report to the OS I set the relevant interrupt bit. However, nothing happens when I do that. I am wondering if I have the right interrupt bit? I am using bits 8 and 9 (decimal). I am not sure how to find out which bit I should be setting. Can anyone help? Regards Rob From litt at ieee.org Sun May 19 05:58:27 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 05:58:27 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <030e01ce546e$67754f00$365fed00$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> Message-ID: <5198A243.8080000@ieee.org> First, remember: COMMENT @ EHPL MI RTPADE NIISED A DP1P1 END OF COMMENT @ Besides setting the correct bit(s), you need to tell simh to generate the interrupt (to the proper vector). Assuming you're doing that, from the KDP's point of view you first need to set rdyo or rdyi, indicate the interrupt directions with iot, the command type, line number... Here are the KDP bit definitions from TOPS-10 , and the most interesting interrupt service code. It's pretty readable; it uses fewer macros than the TOPS-20 driver. The constants are all octal, based as offsets from the CSR base. If you need the other routines, see http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/mon/d8kint.mac.html The KDPAIV and KDPBIV routines are the two generic KDP interrupt service routines; each KDP has small prefix routines that dispatch to them after saving/setting up the registers. The instructions RDIO and WRIO read/write Unibus space. The register address is the second argument, the contents are loaded to / stored from the first argument. If you scan the full source for them, you can see how each register is used. If you need more help, you'll need to provide more details of what is - and isn't - happening. SUBTTL DEFINITIONS -- DUP11 DUPADR==3760300 ;ADDRESS OF 1ST DUP11 DUPUBN==3 ;UNIBUS ADAPTER NUMBER FOR DUP11 DPRCSR==0 ;RECEIVER CSR DPDTR==000002 ;DATA TERMINAL READY DPRDBF==2 ;(RO)RECEIVER DATA BUFFER DPPCSR==2 ;(WO)PARAMETER CONTROL AND STATUS REGISTER DPTCSR==4 ;TRANSMIT CONTROL AND STATUS REGISTER DPCBLP==010000 ;EXTERNAL MAINTENCE MODE (CABLE LOOPBACK) DPCNLP==004000 ;SYSTEMS TEST MODE (CONTROLLER LOOPBACK) DPMAIN==014000 ;MAINTAINENCE MODE BITS DPTDBF==6 ;TRANSMIT DATA BUFFER SUBTTL DEFINITIONS -- KMC11 SEL0==0 BSEL1==1 KMCRUN==100000 ;RUN FLOP KMCMCL==040000 ;MASTER CLEAR KMCCWR==020000 ;CRAM WRITE KMCSLU==010000 ;STEP LINE UNIT KMCLUL==004000 ;LINE UNIT LOOP KMCRMO==002000 ;ROM OUTPUT KMCRMI==001000 ;ROM INPUT KMCSUP==000400 ;STEP u-PROCESSOR KMCRQI==000200 ;REQUEST INPUT KMCIEO==000020 ;INTERRUPT ENABLE OUTPUT KMCIEI==000001 ;INTERRUPT ENABLE INPUT SEL2==2 BSEL3==3 ;CONTAINS LINE NUMBER KMCOVR==100000 ;KMC BUFFER OVER-RUN KMCRDO==000200 ;READY FOR OUTPUT KMCRDI==000020 ;READY FOR INPUT KMCIOT==000004 ;SET FOR RECEIVE CLEARED FOR TRANSMIT KMCTYP==000003 ;COMMAND TYPE BASEIN==000003 ;BASE IN CNTLIN==000001 ;CONTROL IN BFADIN==000000 ;BUFFER ADDRESS IN CNTLOU==000001 ;CONTROL OUT BFADOU==000000 ;BUFFER ADDRESS OUT SEL4==4 BSEL5==5 ;BUFFER DESCRIPTOR LIST ADDRESS ; (BUFFER ADR IN & OUT & CONTROL OUT) SEL6==6 BSEL7==7 ;140000 ;ADR BITS 17 & 16 ; (BUFFER ADR IN & OUT & CONTROL OUT) BFREOM==010000 ;END OF MESSAGE (BUFFER ADR OUT) BFRENB==020000 ;BUFFER ENABLE (BUFFER ADR IN) BFRKIL==010000 ;BUFFER KILL (BUFFER ADR IN) CSRMSK==017770 ;MASK FOR DUP11 CSR ADR (BASE IN) CDDCMP==100000 ;FLAG THIS A DDCMP LINE (CONTROL IN) CHALFD==020000 ;FLAG THIS IS HALF DUPLEX (CONTROL IN) ;010000 ;ENABLE SECONDARY STATION (CONTROL IN) ;001000 ;CRC INHIBIT (CONTROL IN) CENABL==000400 ;FLAG TO ENABLE LINE (CONTROL IN) COUERR==000377 ;ERROR CODE (CONTROL OUT) CRAMSZ==2000 ;SIZE OF KMC11 CRAM DRAMSZ==2000 ;SIZE OF KMC11 DRAM ;BUFFER DESCRIPTOR LISTS ARE STRINGS OF 3 16 BIT WORDS ; 1ST WORD 16 BITS OF BUFFER ADDRESS ; 2ND WORD 16 BIT BYTE COUNT ; 3RD WORD BDLLDS==100000 ;LAST DESCRIPTOR BDLRSY==010000 ;RESYNC TRANSMITTER BDLXAD==006000 ;BUFFER ADDRESS BITS 17 & 16 BDLEOM==001000 ;END OF MESSAGE BDLSOM==000400 ;START OF MESSAGE ;MESSAGES TO THE KMC11 ; BASEIN: BSEL2/ *400+3 ; BSEL6/ &017770 ; CONTROL IN: BSEL2/ *400+1 ; BSEL6/ FLAGS ; BF AD IN: BSEL2/ *400+0+<4 IF INPUT> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ FLAGS ; BF AD OUT: BSEL2/ *400+0+<4 IF RECEIVE> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ FLAGS ; CONTROL OUT: BSEL2/ *400+1+<4 IF RECEIVE> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ ERROR CODE ;CONTROL OUT BIT MASK DEFINITIONS. THE ROUTINE "CTOTLY" TAKES A ; CONTROL OUT CODE, TALLYS THE CONTROL OUT IN THE KDL BLOCK, AND ; PRODUCES A BIT VECTOR OF ONE BIT REPRESENTING THE CODE. THIS ; BIT VECTOR REPRESENTATION IS USED TO FACILITATE PARALLEL TESTING ; FOR VARIOUS CONDITIONS. BIT DEFINITIONS ARE: CTLO06==040000 ;ABORT. SHOULD NEVER HAPPEN CTLO10==020000 ;HEADER CRC ERROR. CTLO12==010000 ;DATA CRC ERROR. CTLO14==004000 ;NO RECEIVE BUFFER ASSIGNED CTLO16==002000 ;DATA SET READY TRANSITION CTLO20==001000 ;KMC-11 GOT A NXM ON A UNIBUS ADDRESS CTLO22==000400 ;TRANSMIT UNDERRUN. CTLO24==000200 ;RECEIVE OVERRUN CTLO26==000100 ;BUFFER KILL COMPLETE SUBTTL INTERRUPTS -- INTERRUPT LEVEL INTERFACE TO THE KMC-11 Comment @ Each KMC-11 has two interrupt vector addresses. "A" This interrupt is taken when RDYI (KMCRDI) comes up. In this state the KMC-11 is ready for an input transaction. All input transactions for the KMC-11 are queued in the KDP block. This is necessary because the following situation would otherwise cause a deadlock. 1) The KMC-11 sets RDYO and gives a BUFFER-OUT transaction. 2) At interrupt level, we want to do a BUFFER-IN. 3) If, in the meantime, the KMC-11 has set RDYO again, we will not be able to get RDYI until we process another output transaction. The solution to this is to queue all input transactions. This does mean that we have to take an interrupt on each transaction, but it does circumvent the above problem. "B" This interrupt is taken when RDYO (KMCRDO) comes up. In this state the KMC-11 is wants to perform an output transaction. It is these output transactions that drive almost all of the interrupt level KMC/DUP processing. The vector instructions are set up to be JSR's to the locations "KDPAIV", and "KDPBIV" in the KDP block for the KMC-11. These locations contain the 5 or 6 instructions necessary to save the AC's, load "W" with the address of the particular KDP block, and dispatch to either of the two interrupt routines "KDPAIV" or "KDPBIV". End comment @ SUBTTL KDPAIV -- KMC-11 INTERRUPT VECTOR "A" PROCESSING. ;KDPAIV -- ROUTINE TO HANDLE KMC-11 INTERRUPT VECTOR "A" (INPUT) ;CALL MOVE W,[EXP KDP-BLOCK-ADDRESS] ; PUSHJ P,KDPAIV ;CALLED FROM KDPIVA IN THE KDP BLOCK ;RETURN POPJ P, ;TO DISMISS THE INTERRUPT. ; ;CLOBBERS MOST AC'S (WE SHOULD HAVE OUR OWN AC BLOCK ANYWAY) ; ;ON MULTI-PROCESSOR SYSTEMS, THIS CODE WILL NEED TO AOSE THE KDP INTERLOCK ; KDPAIV::AOS KDPACT(W) ;COUNT THE INTERRUPT MOVE T1,KDPSTS(W) ;GET THE STATUS TLNN T1,(KDPSRU) ; AND MAKE SURE WE THINK WE'RE ON LINE PJSP T1,KDPERR ; IF WE DON'T, CLEAR "RUN" SO INTS WILL STOP MOVE U,KDPCSR(W) ;GET THE UNIBUS ADDRESS OF THE KMC-11 MOVEI T1,KMCRDI ;GET THE "RDYI" FLAG TION T1,SEL2(U) ;MAKE SURE "RDYI" IS UP PJSP T1,KDPERR ; IF IT'S NOT, THEN ITS AN ILLEGAL INTERRUPT MOVE T3,KDPIQT(W) ;GET NUMBER OF NEXT QUEUED TRANSACTION CAMN T3,KDPIQP(W) ;MAKE SURE THAT IT'S DIFFERENT NOT THE "PUTTER" PJSP T1,KDPERR ; IF IT IS, THEN WE'RE GETTINT UNSOLICITED ; INTERRUPTS. DECLARE KDP ILL. LSH T3,1 ;MAKE IT AN OFFSET INTO THE QUEUE ADDI T3,KDPINQ(W) ;RELOCATE BY THE ADDRESS OF THE QUEUE MOVE T1,0(T3) ;GET SEL2 DATA MOVE T2,1(T3) ;GET SEL4, SEL6 DATA AOS T3,KDPIQT(W) ;ADVANCE QUEUE TAKER CAIL T3,KDPQLN ;IF ITS TIME TO WRAP AROUND, THEN SETZB T3,KDPIQT(W) ; WRAP AROUND TO THE FIRST ENTRY MOVEI T4,KMCRQI ;GET THE REQUEST INPUT INTERRUPT BIT CAMN T3,KDPIQP(W) ;IF QUEUE EMPTY (PUTTER = TAKER) THEN BCIO T4,SEL0(U) ; CLEAR RQI TO STOP THE INTERRUPTS WRIO T2,SEL6(U) ;STORE TOP WORD MOVSS T2,T2 ;GET SEL4 DATA WRIO T2,SEL4(U) ; AND STORE THAT TRZ T1,KMCRDI ;MAKE SURE RDYI CLEAR (SO KMC CAN RUN) WRIO T1,SEL2(U) ;GIVE REST OF DATA TO KMC POPJ P, ;ALL DONE ;KDPBIV -- ROUTINE TO HANDLE KMC-11 INTERRUPT VECTOR "B" (OUTPUT) ;CALL MOVE W,[EXP KDP-BLOCK-ADDRESS] ; PUSHJ P,KDPBIV ;CALLED FROM KDPIVB IN THE KDP BLOCK ;RETURN POPJ P, ;TO DISMISS THE INTERRUPT ; ;CLOBBERS MOST AC'S (WE SHOULD HAVE OUR OWN AC BLOCK ANYWAYS) ; ;ON MULTI-PROCESSOR SYSTEMS THIS CODE WILL NEED TO AOSE THE KDP INTERLOCK. ; KDPBIV::AOS KDPBCT(W) ;COUNT THE INTERRUPT MOVE T1,KDPSTS(W) ;GET OUR PERCEIVED STATUS TLNN T1,(KDPSRU) ; AND MAKE SURE WE THINK WE'RE RUNNING PJSP T1,KDPERR ; IF WE'RE NOT, CLEAR RUN AND RETURN MOVE U,KDPCSR(W) ;GET THE UNIBUS ADDRESS OF THE KMC RDIO P1,SEL2(U) ;READ STATUS BITS TRNN P1,KMCRDO ;BETTER WANT AN OUTPUT TRANSACTION PJSP T1,KDPERR ;ILLEGAL INTERRUPT. CRASH KMC RDIO P2,SEL4(U) ;READ BDL ADDRESS RDIO P3,SEL6(U) ;READ ERROR, STATUS OR WHAT EVER MOVEI T1,KMCRDO ;GET THE RDYO BIT BCIO T1,SEL2(U) ;CLEAR IT TO LET THE KMC CONTINUE TRNE P1,2!KMCOVR ;MAKE SURE TYPE IS RIGHT, AND NO OVERRUN PJSP T1,KDPERR ; WE'RE CONFUSED. GIVE UP. LDB F,[POINT 7,P1,27] ;GET 7 BIT LINE #. CAML F,KDPDPN(W) ;IS THIS A LEGAL LINE FOR THIS KDP PJSP T1,KDPERR ; IF NOT, BETTER STOP NOW... ADDI F,KDPKDL(W) ;MAKE IT AN OFFSET INTO THE KDP BLOCK HRRZ F,(F) ;LOAD APPRIOATE KDL BLOCK ADDRESS SETZ T1, ;GET A ZERO REGISTER TRNE P1,KMCIOT ;IF INPUT, THEN TRO T1,1 ; SET LOW ORDER BIT TRNE P1,1 ;IF CONTROL, THEN TRO T1,2 ; SET NEXT TO LOW ORDER BIT JRST @[JRST KDPBOO ;BUFFER OUT (OUTPUT) JRST KDPBOI ;BUFFER OUT (INPUT) JRST KDPCOO ;CONTROL OUT (OUTPUT) JRST KDPCOI](T1);CONTROL OUT (INPUT) ;ROUTINE DISPATCHED TO WILL RETURN. SUBTTL KDPBOO -- KMC-11 BUFFER-OUT(OUTPUT) TRANSACTION PROCESSING. ; This routine frees output buffers when a BUFFER-OUT(OUTPUT) transaction ;declares that the KMC/DUP has output all data in the buffer. It: ; 1) Makes sure that this is the last buffer in the current ; Buffer Description List. (Data messages consist of two ; buffers. The DDCMP header buffer, and the data buffer. ; These two buffers are combined in a single BDL) If ; the current buffer is not the last in the list, nothing ; more is done, and the interrupt is exited. (We will ; get another interrupt when the next buffer in the BDL ; finishes.) ; 2) The count of buffers outstanding is decremented, and a ; check is made to ensure that this buffer is really the ; next one we expected to finish. ; 3) XMTBUF is called in an attempt to fill the just freed output ; buffer. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPBOO: PUSHJ P,GETBDL ;GET T4 SET UP TO POINT TO BDL TLNE T4,1 ;MAKE SURE THAT BUFFER-OUT STARTS ON EVEN BYTE PJSP T1,KDPERR ; IF ODD BYTE, THEN KMC-11 SCREWED US MOVE T1,1(T4) ;GET WORD WITH LAST BD HALFWORD TLNN T4,2 ;IF WE WANT FIRST HALFWORD, MOVS T1,T1 ; THEN SWAP IT TO THE LOW HALF TRNN T1,BDLLDS ;IS THIS THE LAST BUFFER IN THE BDL POPJ P, ;IF NOT, IGNORE THIS INTERRUPT. ;WE ARE AT END OF MESSAGE. MAKE SURE WE GOT THE RIGHT ONE BACK MOVEI S,KDSNXB ;STATUS BIT THAT SAYS WHICH BUFFER IS NEXT OUT MOVEI T1,KDLXD1(F) ;ASSUME THAT BUFFER #1 IS FIRST BACK TDNE S,KDLSTS(F) ; BUT IF IT SHOULD BE BUFFER #2, THEN MOVEI T1,KDLXD2(F) ; THEN CHANGE OUR MIND. MOVSI T2,(1B0) ;GET THE BDL IN-USE MARK BIT TDNN T2,0(T1) ; AND MAKE SURE THAT IT'S SET ;[DBUG] PJSP T1,KDLERR ;IF NOT, TRY TO CRASH THE LINE PUSHJ P,NTDSTP## ;WE'VE SCREWED UP THE BUFFERS [DBUG] ANDCAM T2,0(T1) ;CLEAR THE USE BIT HLRZ T3,1(T1) ;GET THE HALFWORD CONTAINING THE 3RD WORD ; OF THE FIRST BD IN THE BDL TRNN T3,BDLLDS ;IF IT'S NOT THE LAST BD, THEN ADD T1,[XWD 2,1] ; ADVANCE THE CBP IN T1 3 WORDS (6 BYTES) CAMN T1,T4 ;MAKE SURE IT'S THE BDL ADDRESS THE KMC GAVE US SOSGE KDLXBC(F) ;DECREMENT THE NUMBER OF ACTIVE OUTPUT BUFFERS PJSP T1,KDPERR ;++ EITHER BAD BUFFER, OF COUNT WENT NEGATIVE. XORB S,KDLSTS(F) ;SIGNAL THAT OTHER BUFFER IS NEXT BUFFER OUT PJRST XMTBUF ;NOW GO TRY TO FILL THE JUST FREED BUFFER SUBTTL KDPBOI -- ROUTINE TO HANDLE BUFFER-OUT(INPUT) TRANSACTIONS. ; This routine handles BUFFER-OUT(INPUT) transactions. These ;transactions consist of input messages coming in over the synchronous ;line. This routine: ; 1) Frees the receive buffer. (No worry about races, this ; code runs under the KMC interlock on multiprocessor ; systems. On a single processor system, it runs at ; interrupt level. Hence no one will try to allocate ; the buffer between when it is freed and when it is ; processed ; 2) Calls RCVMSG to process the incoming message ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPBOI: PUSHJ P,FREBOI ;FREE THE INPUT BUFFER, (SET UP T4) PJSP T1,KDPERR ;?? KMC-11 GAVE BAD BDL ADDRESS ?? PJRST RCVMSG ;GO PROCESS MESSAGE (T4 POINTS TO BDL) SUBTTL KDPCOO -- PROCESS A CONTROL-OUT(OUTPUT) TRANSACTION ; This routine processes CONTROL-OUT(OUTPUT) transactions. These ;consist primarily of various errors detected by the KMC-11. This routine: ; 1) Counts the control out transaction code (CTOTLY) ; 2) Verifys that the error is legal/recoverable. If not, ; it crashes the KMC-11. ; 3) If the control out frees an output BDL, it assumes that ; an output message has been clobbered, queues a REP message ; to speed a recovery NAK, and calls "KDPBOO" to free the BDL. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPCOO: PUSHJ P,SAVE1## ;WE USE P1 FOR A "BIT MASK" PUSHJ P,CTOTLY ;TALLY THE CONTROL OUT CODE AND ; PUT "BIT MASK" IN P1 PJSP T1,KDPERR ;IF ILLEGAL CODE, KMC-11 IS SICK... TLNE P1,^- ;THESE ARE LEGAL OUTPUT PJSP T1,KDPERR ; IF IT'S NOT ONE OF THEM, CRASH KMC-11 TLNE P1,CTLO14 ;IS THIS A BUFFER TEMP UNAVAILABLE? JRST [MOVEI T1,RSNBTU ;IF SO, GET THAT NAK CODE PJRST RCVXNK] ;SEND THE NAK AND RETURN TLNE P1,CTLO26 ;IF THIS A "FLUSH DONE" TRANSACTION JRST KDPFLO ; IF FLUSH DONE, GO UPDATE KDLSTS TLNN P1,CTLO22 ;DOES THIS TRANSACTION FREE A BDL? POPJ P, ; IF NOT, RETURN (DON'T CALL XMTBUF...) MOVSI T1,(KDSREP) ;ASSUME MESSAGE WAS CLOBBERED, SO IORM T1,KDLSTS(F) ; SO REQUEST A REP TO SPEED RECOVERY PJRST KDPBOO ;PROCESS REST JUST LIKE ANY OTHER BUFFER-OUT SUBTTL KDPCOI -- PROCESS CONTROL-OUT(INPUT) TRANSACTIONS ; This routine processes the CONTROL-OUT(INPUT) transactions. These ;transactions are primarily errors noticed by the KMC-11. In particular, ;BCC (checksum) errors are processed here. This routine: ; 1) Tallys the CONTROL-OUT transaction ; 2) Sees if it is a legal/recoverable error. If not, it ; crashes the KMC-11 ; 3) If the transaction frees an input buffer, that is done. ; 4) If the transaction implies that a message was lost, ; an approiate NAK is queued. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPCOI: PUSHJ P,SAVE1## ;P1 WILL HAVE THE "BIT MASK" IN IT. PUSHJ P,CTOTLY ;TALLY THE CONTROL OUT TYPE ; RETURNS "BIT MASK" IN P1 PJSP T1,KDPERR ;UNKNOWN CODE. KMC-11 IS SICK... TLNE P1,^- ;IS THIS LEGAL FOR INPUT PJSP T1,KDLERR ;UN-RECOVERABLE ERROR. BETTER START OVER TLNE P1,CTLO26 ;IS THIS AN "INPUT FLUSH" DONE TRANSACTION JRST KDPFLI ; IF INPUT FLUSH, GO UPDATE KDLSTS TLNE P1, ;DOES THIS FREE A BDL? PUSHJ P,[PUSHJ P,FREBOI ;FREE THE INPUT BDL PJSP T1,KDLERR ;BAD ADDRESS RETURNED BY KMC-11. DIE POPJ P,] ;RETURN TO MAIN FLOW TLNN P1, ;DOES THIS REQUIRE A NAK? PJRST RCVBUF ;IF NO NAK REQUIRED, WE ARE DONE ; ATTEMPT TO REQUEUE A BUFFER AND RETURN MOVEI T1,RSNHCK ;ASSUME THAT ERROR WAS HEADER CHECKSUM TLNE P1,CTLO12 ; BUT IF IT WAS A DATA CHECKSUM MOVEI T1,RSNDCK ; THEN CHANGE OUR MINDS AND USE THAT TLNE P1,CTLO24 ; UNLESS IT WAS AN OVER-RUN, IN WHICH MOVEI T1,RSNOVR ; CASE WE SHOULD USE THIS. PJRST RCVXNK ;QUEUE NAK AND REQUEUE BUFFERS IF POSSIBLE ;KDPFLO ROUTINE TO CLEAN UP WHEN OUTPUT BUFFER FLUSH IS COMPLETED. ; CLEAR "XMIT FLUSH IN PROGRESS" AND SAY NO OUTPUT BUFFERS QUEUED. KDPFLO: LDB T1,KDLSTA## ;GET THE LINE'S STATE (JUST TO MAKE SURE) MOVEI T2,KDSXFL ;GET THE "XMIT FLUSH" IN PROGRESS BIT CAIN T1,KD%FLS ;IF WE'RE NOT IN "BUFFER FLUSH STATE", OR TDNN T2,KDLSTS(F) ; WE'RE NOT FLUSHING XMIT BUFFERS PJSP T1,KDPERR ; THEN ASSUME THE KMC-11 SCREWED UP SETZM KDLXBC(F) ;SAY "NO OUTPUT BUFFERS ACTIVE" MOVEI T1,KDSNXB!KDSXFL; ALSO SAY THAT NEXT BUFFER IS #0, AND ANDCAB T1,KDLSTS(F) ; WE'RE NOT FLUSHING ANY MORE JRST KDPFLX ;SEE IF WE CAN LEAVE "FLUSH" STATE ;KDPFLI ROUTINE TO CLEAN UP WHEN INPUT BUFFER FLUSH IS COMPLETE KDPFLI: LDB T1,KDLSTA## ;GET LINE'S STATE MOVEI T2,KDSRFL ;"RECEIVE FLUSH IN PROGRESS" BIT CAIN T1,KD%FLS ;MAKE SURE WE'RE FLUSHING TDNN T2,KDLSTS(F) ;MAKE SURE IT'S INPUT PJSP T1,KDPERR ;IF NOT INPUT FLUSH, THEN KMC GAVE BAD CODE SETZM KDLRBC(F) ;ZERO COUNT OF RECEIVE BUFFERS POSTED MOVEI T1,KDSNRB!KDSRFL;SAY BUFFER #0 NEXT, AND ANDCAB T1,KDLSTS(F) ; INPUT FLUSH COMPLETE KDPFLX: MOVEI T2,KD%INI ;ASSUME THAT WE HAVE CLEARED BOTH FLUSH BITS TRNN T1,KDSRFL!KDSXFL; AND IF WE HAVE, DPB T2,KDLSTA## ; THEN WE'RE IN "INITED" STATE POPJ P, ;DONE WITH THE INTERRUPT This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 04:53, Robert Jarratt wrote: >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Rich Alderson >> Sent: 08 May 2013 01:02 >> To: hecnet at update.uu.se; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >>> From: "Robert Jarratt" >>> Date: Tue, 7 May 2013 23:33:36 +0100 >>> Can anyone point me at the right place to look at TOPS-20 driver code >>> for the KMC11? I can see that it is trying to get the Microprocessor >>> to do something and read back some values, but I don't know what >>> values it wants to get and so it reports: >> Hi, Rob, >> >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >> >> You want the file KDPSRV.MAC in that directory. >> >> Rich >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > I am making some progress with getting the KMC/DUP emulation working in SIMH > for TOPS-20. At the moment I am stuck on one thing, which is the interrupts > to tell the OS that the KMC has processed a buffer. The OS sets the > interrupt enable bit and when I have something to report to the OS I set the > relevant interrupt bit. However, nothing happens when I do that. I am > wondering if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). > > I am not sure how to find out which bit I should be setting. > > Can anyone help? > > Regards > > Rob > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Sun May 19 06:26:14 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 06:26:14 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <030e01ce546e$67754f00$365fed00$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> Message-ID: <5198A8C6.7030706@ieee.org> A couple of other things come to mind (naturally, after pushing 'send'): Initialization will load/verify the microcode. That has to work. After setting RUN and the interrupt enables, expect base-in and control-in command to establish the DUP CSR address, buffers, line mode/enable. These require that the KMC respond to KMCRQI by initiating an A vector interrupt. Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit clear (BCIO) instructions that also touch the KMC. For better directed hints, I'd need more detail on what is and isn't happening. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 04:53, Robert Jarratt wrote: >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Rich Alderson >> Sent: 08 May 2013 01:02 >> To: hecnet at update.uu.se; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >>> From: "Robert Jarratt" >>> Date: Tue, 7 May 2013 23:33:36 +0100 >>> Can anyone point me at the right place to look at TOPS-20 driver code >>> for the KMC11? I can see that it is trying to get the Microprocessor >>> to do something and read back some values, but I don't know what >>> values it wants to get and so it reports: >> Hi, Rob, >> >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >> >> You want the file KDPSRV.MAC in that directory. >> >> Rich >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > I am making some progress with getting the KMC/DUP emulation working in SIMH > for TOPS-20. At the moment I am stuck on one thing, which is the interrupts > to tell the OS that the KMC has processed a buffer. The OS sets the > interrupt enable bit and when I have something to report to the OS I set the > relevant interrupt bit. However, nothing happens when I do that. I am > wondering if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). > > I am not sure how to find out which bit I should be setting. > > Can anyone help? > > Regards > > Rob > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 07:42:59 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 12:42:59 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198A8C6.7030706@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> Message-ID: <034b01ce5486$06b04810$1410d830$@ntlworld.com> Thanks Timothe, I am pretty sure I am doing all the things you mention already (sorry I didn't make that clear), but I will check through everything you have said, just in case I have missed something. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 11:26 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > A couple of other things come to mind (naturally, after pushing 'send'): > > Initialization will load/verify the microcode. That has to work. > > After setting RUN and the interrupt enables, expect base-in and control-in > command to establish the DUP CSR address, buffers, line mode/enable. > These require that the KMC respond to KMCRQI by initiating an A vector > interrupt. > > Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit clear > (BCIO) instructions that also touch the KMC. > > For better directed hints, I'd need more detail on what is and isn't happening. > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 04:53, Robert Jarratt wrote: > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Rich Alderson > >> Sent: 08 May 2013 01:02 > >> To: hecnet at update.uu.se; simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >>> From: "Robert Jarratt" > >>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>> right place to look at TOPS-20 driver code for the KMC11? I can see > >>> that it is trying to get the Microprocessor to do something and read > >>> back some values, but I don't know what values it wants to get and > >>> so it reports: > >> Hi, Rob, > >> > >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html > >> > >> You want the file KDPSRV.MAC in that directory. > >> > >> Rich > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > I am making some progress with getting the KMC/DUP emulation working > > in SIMH for TOPS-20. At the moment I am stuck on one thing, which is > > the interrupts to tell the OS that the KMC has processed a buffer. The > > OS sets the interrupt enable bit and when I have something to report > > to the OS I set the relevant interrupt bit. However, nothing happens > > when I do that. I am wondering if I have the right interrupt bit? I am > > using bits 8 and 9 (decimal). > > > > I am not sure how to find out which bit I should be setting. > > > > Can anyone help? > > > > Regards > > > > Rob > > > > _______________________________________________ > > Simh mailing list > > Simh at trailing-edge.com > > http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Sun May 19 09:54:10 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 09:54:10 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <034b01ce5486$06b04810$1410d830$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> Message-ID: <5198D982.80809@ieee.org> > I am pretty sure I am doing all the things you mention already Then I need a trace of what's happening to the registers, and what simh thinks it's doing with the interrupts. (It would be easiest to follow if you output both octal and decode the register names/fields, though I can still think - slowly- in octal.) Also, I thought this code was working for the -11/VAX. If so, the basics must be OK, though the drivers may well take a different approach to the device. Received data should produce either a control-out (error, e.g. no buffer available or DSR change or NXM...) or a buffer-out B interrupt. The message must fit in 1 buffer. Errors may implicitly free a BDL... Transmit done - also note that we ignore interrupts unless the 'last buffer' bit is set. (The DDCMP header and data are in two BDL segments, and require two interrupts.) Finally, I'm not sure if you'll see it used, but there is code in the TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to force the microcontroller to execute several known instructions - to access its data ram, registers & PC. This is primarily used to dump a KMC that halts - it doesn't seem to be used when the built-in ucode is loaded. But some of these are also used to verify data ram at initialization. Failure to verify will cause the device to be disabled. We can go down that path if you see those bits being set in a trace. Look for KMCXCT calls in http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor-sources/kdpsrv.mac.html TOPS-10 doesn't do this. The microinstructions are defined in http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP-PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Manual.pdf The subset is pretty small - load address register, load/store indirect (with increment), & branch. I think you ought to be able to crash simh if an unknown instruction is forced, including a branch to an address other than 0. Ugly device, ugly driver. Sigh. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 07:42, Robert Jarratt wrote: > Thanks Timothe, > > I am pretty sure I am doing all the things you mention already (sorry I > didn't make that clear), but I will check through everything you have said, > just in case I have missed something. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Timothe Litt >> Sent: 19 May 2013 11:26 >> To: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> A couple of other things come to mind (naturally, after pushing 'send'): >> >> Initialization will load/verify the microcode. That has to work. >> >> After setting RUN and the interrupt enables, expect base-in and control-in >> command to establish the DUP CSR address, buffers, line mode/enable. >> These require that the KMC respond to KMCRQI by initiating an A vector >> interrupt. >> >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit > clear >> (BCIO) instructions that also touch the KMC. >> >> For better directed hints, I'd need more detail on what is and isn't > happening. >> This communication may not represent my employer's views, if any, on the >> matters discussed. >> >> On 19-May-13 04:53, Robert Jarratt wrote: >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Rich Alderson >>>> Sent: 08 May 2013 01:02 >>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>>> From: "Robert Jarratt" >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>> right place to look at TOPS-20 driver code for the KMC11? I can see >>>>> that it is trying to get the Microprocessor to do something and read >>>>> back some values, but I don't know what values it wants to get and >>>>> so it reports: >>>> Hi, Rob, >>>> >>>> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >>>> >>>> You want the file KDPSRV.MAC in that directory. >>>> >>>> Rich >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> I am making some progress with getting the KMC/DUP emulation working >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which is >>> the interrupts to tell the OS that the KMC has processed a buffer. The >>> OS sets the interrupt enable bit and when I have something to report >>> to the OS I set the relevant interrupt bit. However, nothing happens >>> when I do that. I am wondering if I have the right interrupt bit? I am >>> using bits 8 and 9 (decimal). >>> >>> I am not sure how to find out which bit I should be setting. >>> >>> Can anyone help? >>> >>> Regards >>> >>> Rob >>> >>> _______________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 10:20:40 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 15:20:40 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198D982.80809@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> Message-ID: <035801ce549c$0d6c3630$2844a290$@ntlworld.com> I have made some progress. I realised that I did not have the interrupt acknowledgement routines set up in the DIB. It is working a bit better now. I have indeed seen some commands to read the ram and verify the microcode, it does all this to check the KMC is working before enabling it. This particular code has never (as far as I know) worked for the 11 or the VAX. I wrote the DMC11 code for those. This code I am working with now came from someone else and was written for the PDP1) for a much older version of SIMH. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 14:54 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > I am pretty sure I am doing all the things you mention already > Then I need a trace of what's happening to the registers, and what simh > thinks it's doing with the interrupts. (It would be easiest to follow > if you output both octal and decode the register names/fields, though I can > still think - slowly- in octal.) > > Also, I thought this code was working for the -11/VAX. If so, the basics must > be OK, though the drivers may well take a different approach to the device. > > Received data should produce either a control-out (error, e.g. no buffer > available or DSR change or NXM...) or a buffer-out B interrupt. The message > must fit in 1 buffer. Errors may implicitly free a BDL... > > Transmit done - also note that we ignore interrupts unless the 'last buffer' bit > is set. (The DDCMP header and data are in two BDL segments, and require > two interrupts.) > > Finally, I'm not sure if you'll see it used, but there is code in the > TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to > force the microcontroller to execute several known instructions - to access its > data ram, registers & PC. This is primarily used to dump a KMC that halts - it > doesn't seem to be used when the built-in ucode is loaded. But some of > these are also used to verify data ram at initialization. Failure to verify will > cause the device to be disabled. We can go down that path if you see those > bits being set in a trace. > > Look for KMCXCT calls in > http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > sources/kdpsrv.mac.html > TOPS-10 doesn't do this. The microinstructions are defined in > http://bitsavers.trailing- > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > nual.pdf > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > 0Manual.pdf> > The subset is pretty small - load address register, load/store indirect (with > increment), & branch. I think you ought to be able to crash simh if an > unknown instruction is forced, including a branch to an address other than 0. > > Ugly device, ugly driver. Sigh. > > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 07:42, Robert Jarratt wrote: > > Thanks Timothe, > > > > I am pretty sure I am doing all the things you mention already (sorry > > I didn't make that clear), but I will check through everything you > > have said, just in case I have missed something. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Timothe Litt > >> Sent: 19 May 2013 11:26 > >> To: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> A couple of other things come to mind (naturally, after pushing 'send'): > >> > >> Initialization will load/verify the microcode. That has to work. > >> > >> After setting RUN and the interrupt enables, expect base-in and > >> control-in command to establish the DUP CSR address, buffers, line > mode/enable. > >> These require that the KMC respond to KMCRQI by initiating an A > >> vector interrupt. > >> > >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and > >> bit > > clear > >> (BCIO) instructions that also touch the KMC. > >> > >> For better directed hints, I'd need more detail on what is and isn't > > happening. > >> This communication may not represent my employer's views, if any, on > >> the matters discussed. > >> > >> On 19-May-13 04:53, Robert Jarratt wrote: > >>>> -----Original Message----- > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>> edge.com] On Behalf Of Rich Alderson > >>>> Sent: 08 May 2013 01:02 > >>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>> > >>>>> From: "Robert Jarratt" > >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>>>> right place to look at TOPS-20 driver code for the KMC11? I can > >>>>> see that it is trying to get the Microprocessor to do something > >>>>> and read back some values, but I don't know what values it wants > >>>>> to get and so it reports: > >>>> Hi, Rob, > >>>> > >>>> http://pdp-10.trailing- > edge.com/tops20v41_monitor_sources/index.htm > >>>> l > >>>> > >>>> You want the file KDPSRV.MAC in that directory. > >>>> > >>>> > >>>> Rich _______________________________________________ > >>>> Simh mailing list > >>>> Simh at trailing-edge.com > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>> I am making some progress with getting the KMC/DUP emulation > working > >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which is > >>> the interrupts to tell the OS that the KMC has processed a buffer. > >>> The OS sets the interrupt enable bit and when I have something to > >>> report to the OS I set the relevant interrupt bit. However, nothing > >>> happens when I do that. I am wondering if I have the right interrupt > >>> bit? I am using bits 8 and 9 (decimal). > >>> > >>> I am not sure how to find out which bit I should be setting. > >>> > >>> Can anyone help? > >>> > >>> Regards > >>> > >>> Rob > >>> > >>> _______________________________________________ > >>> Simh mailing list > >>> Simh at trailing-edge.com > >>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 19 11:01:28 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 16:01:28 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <035801ce549c$0d6c3630$2844a290$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> Message-ID: <036601ce54a1$c1719f80$4454de80$@ntlworld.com> What is curious now is that I have two instances (identical clones) running attempting to talk to each other. The first message one sends to the other crashes the OS: ********** *BUGHLT "KMCIII" AT 19-May-2013 15: *ADDITIONAL DATA: 000000172507, 000000000200 ********** The odd thing is that I have delivered the same data that was sent from the other end, so it should be valid data. The data is: 05 06 C0 00 00 01 That data does not seem to completely match the DDCMP spec I have, I think some checksum is supposed to follow. Is that supposed to be added by the KMC perhaps? I don't fully expect it to work because they are clones so would expect some kind of error, but would not expect a crash, or am I wrong? Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Robert Jarratt > Sent: 19 May 2013 15:21 > To: 'Timothe Litt'; simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > I have made some progress. I realised that I did not have the interrupt > acknowledgement routines set up in the DIB. It is working a bit better now. > > I have indeed seen some commands to read the ram and verify the > microcode, it does all this to check the KMC is working before enabling it. > > This particular code has never (as far as I know) worked for the 11 or the > VAX. I wrote the DMC11 code for those. This code I am working with now > came from someone else and was written for the PDP1) for a much older > version of SIMH. > > Regards > > Rob > > > -----Original Message----- > > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > edge.com] On Behalf Of Timothe Litt > > Sent: 19 May 2013 14:54 > > To: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > I am pretty sure I am doing all the things you mention already > > Then I need a trace of what's happening to the registers, and what simh > > thinks it's doing with the interrupts. (It would be easiest to follow > > if you output both octal and decode the register names/fields, though > > I > can > > still think - slowly- in octal.) > > > > Also, I thought this code was working for the -11/VAX. If so, the > > basics > must > > be OK, though the drivers may well take a different approach to the > device. > > > > Received data should produce either a control-out (error, e.g. no > > buffer available or DSR change or NXM...) or a buffer-out B interrupt. > > The > message > > must fit in 1 buffer. Errors may implicitly free a BDL... > > > > Transmit done - also note that we ignore interrupts unless the 'last > buffer' bit > > is set. (The DDCMP header and data are in two BDL segments, and > > require two interrupts.) > > > > Finally, I'm not sure if you'll see it used, but there is code in the > > TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to > > force the microcontroller to execute several known instructions - to > access its > > data ram, registers & PC. This is primarily used to dump a KMC that > > halts > - it > > doesn't seem to be used when the built-in ucode is loaded. But some > > of these are also used to verify data ram at initialization. Failure > > to > verify will > > cause the device to be disabled. We can go down that path if you see > those > > bits being set in a trace. > > > > Look for KMCXCT calls in > > http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > sources/kdpsrv.mac.html > > TOPS-10 doesn't do this. The microinstructions are defined in > > http://bitsavers.trailing- > > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > nual.pdf > > > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > 0Manual.pdf> > > The subset is pretty small - load address register, load/store > > indirect > (with > > increment), & branch. I think you ought to be able to crash simh if > > an unknown instruction is forced, including a branch to an address > > other than > 0. > > > > Ugly device, ugly driver. Sigh. > > > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 07:42, Robert Jarratt wrote: > > > Thanks Timothe, > > > > > > I am pretty sure I am doing all the things you mention already > > > (sorry I didn't make that clear), but I will check through > > > everything you have said, just in case I have missed something. > > > > > > Regards > > > > > > Rob > > > > > >> -----Original Message----- > > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > >> edge.com] On Behalf Of Timothe Litt > > >> Sent: 19 May 2013 11:26 > > >> To: simh at trailing-edge.com > > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> A couple of other things come to mind (naturally, after pushing > 'send'): > > >> > > >> Initialization will load/verify the microcode. That has to work. > > >> > > >> After setting RUN and the interrupt enables, expect base-in and > > >> control-in command to establish the DUP CSR address, buffers, line > > mode/enable. > > >> These require that the KMC respond to KMCRQI by initiating an A > > >> vector interrupt. > > >> > > >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) > > >> and bit > > > clear > > >> (BCIO) instructions that also touch the KMC. > > >> > > >> For better directed hints, I'd need more detail on what is and > > >> isn't > > > happening. > > >> This communication may not represent my employer's views, if any, > > >> on the matters discussed. > > >> > > >> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>> -----Original Message----- > > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>> edge.com] On Behalf Of Rich Alderson > > >>>> Sent: 08 May 2013 01:02 > > >>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>> > > >>>>> From: "Robert Jarratt" > > >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > > >>>>> right place to look at TOPS-20 driver code for the KMC11? I can > > >>>>> see that it is trying to get the Microprocessor to do something > > >>>>> and read back some values, but I don't know what values it wants > > >>>>> to get and so it reports: > > >>>> Hi, Rob, > > >>>> > > >>>> http://pdp-10.trailing- > > edge.com/tops20v41_monitor_sources/index.htm > > >>>> l > > >>>> > > >>>> You want the file KDPSRV.MAC in that directory. > > >>>> > > >>>> > > >>>> Rich _______________________________________________ > > >>>> Simh mailing list > > >>>> Simh at trailing-edge.com > > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>> I am making some progress with getting the KMC/DUP emulation > > working > > >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which > > >>> is the interrupts to tell the OS that the KMC has processed a buffer. > > >>> The OS sets the interrupt enable bit and when I have something to > > >>> report to the OS I set the relevant interrupt bit. However, > > >>> nothing happens when I do that. I am wondering if I have the right > > >>> interrupt bit? I am using bits 8 and 9 (decimal). > > >>> > > >>> I am not sure how to find out which bit I should be setting. > > >>> > > >>> Can anyone help? > > >>> > > >>> Regards > > >>> > > >>> Rob > > >>> > > >>> _______________________________________________ > > >>> Simh mailing list > > >>> Simh at trailing-edge.com > > >>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From litt at ieee.org Sun May 19 12:01:02 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 12:01:02 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <036601ce54a1$c1719f80$4454de80$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> Message-ID: <5198F73E.803@ieee.org> The bugcheck is saying that the RDYO is set, but not RDYI on an A interrupt. (KMCRDI is 20; RDO is 200) RDYO should always go to IVB; RDYI to IVA. Since we took an IVA interrupt, the driver thinks its trying to give the KMC a command, but the interrupt is going to the wrong vector since RDYI is not set. So either you're generating an IVA but setting the wrong status bit, or generating an Ivb event but not to the right vector. Or perhaps you have an overrun - the interrupt has to be cleared when the drive clears the RDx bit. The data looks like a DDCMP start, less the CRCs. That indicates that a fair bit of stuff is working; this is the data that the -10 provides to the KMC. Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. CRC errors are reported by control out bits. Since the KMC both adds on transmit and removes/checks on receive, and you are running over an error-checked transport, you can get away with not simulating this - unless you want to interoperate with an interface that does add the CRCs. Even if the systems are cloned, the DDCMP layer should come up; you'll die later when transport detects a duplicate DECnet node number. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 11:01, Robert Jarratt wrote: > What is curious now is that I have two instances (identical clones) running > attempting to talk to each other. The first message one sends to the other > crashes the OS: > > ********** > *BUGHLT "KMCIII" AT 19-May-2013 15: > *ADDITIONAL DATA: 000000172507, 000000000200 > ********** > > The odd thing is that I have delivered the same data that was sent from the > other end, so it should be valid data. > > The data is: 05 06 C0 00 00 01 > > That data does not seem to completely match the DDCMP spec I have, I think > some checksum is supposed to follow. Is that supposed to be added by the KMC > perhaps? > > I don't fully expect it to work because they are clones so would expect some > kind of error, but would not expect a crash, or am I wrong? > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Robert Jarratt >> Sent: 19 May 2013 15:21 >> To: 'Timothe Litt'; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> I have made some progress. I realised that I did not have the interrupt >> acknowledgement routines set up in the DIB. It is working a bit better > now. >> I have indeed seen some commands to read the ram and verify the >> microcode, it does all this to check the KMC is working before enabling > it. >> This particular code has never (as far as I know) worked for the 11 or the >> VAX. I wrote the DMC11 code for those. This code I am working with now >> came from someone else and was written for the PDP1) for a much older >> version of SIMH. >> >> Regards >> >> Rob >> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>> edge.com] On Behalf Of Timothe Litt >>> Sent: 19 May 2013 14:54 >>> To: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>>> I am pretty sure I am doing all the things you mention already >>> Then I need a trace of what's happening to the registers, and what simh >>> thinks it's doing with the interrupts. (It would be easiest to follow >>> if you output both octal and decode the register names/fields, though >>> I >> can >>> still think - slowly- in octal.) >>> >>> Also, I thought this code was working for the -11/VAX. If so, the >>> basics >> must >>> be OK, though the drivers may well take a different approach to the >> device. >>> Received data should produce either a control-out (error, e.g. no >>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. >>> The >> message >>> must fit in 1 buffer. Errors may implicitly free a BDL... >>> >>> Transmit done - also note that we ignore interrupts unless the 'last >> buffer' bit >>> is set. (The DDCMP header and data are in two BDL segments, and >>> require two interrupts.) >>> >>> Finally, I'm not sure if you'll see it used, but there is code in the >>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to >>> force the microcontroller to execute several known instructions - to >> access its >>> data ram, registers & PC. This is primarily used to dump a KMC that >>> halts >> - it >>> doesn't seem to be used when the built-in ucode is loaded. But some >>> of these are also used to verify data ram at initialization. Failure >>> to >> verify will >>> cause the device to be disabled. We can go down that path if you see >> those >>> bits being set in a trace. >>> >>> Look for KMCXCT calls in >>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>> sources/kdpsrv.mac.html >>> TOPS-10 doesn't do this. The microinstructions are defined in >>> http://bitsavers.trailing- >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>> nual.pdf >>> >> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>> 0Manual.pdf> >>> The subset is pretty small - load address register, load/store >>> indirect >> (with >>> increment), & branch. I think you ought to be able to crash simh if >>> an unknown instruction is forced, including a branch to an address >>> other than >> 0. >>> Ugly device, ugly driver. Sigh. >>> >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 07:42, Robert Jarratt wrote: >>>> Thanks Timothe, >>>> >>>> I am pretty sure I am doing all the things you mention already >>>> (sorry I didn't make that clear), but I will check through >>>> everything you have said, just in case I have missed something. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 11:26 >>>>> To: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> A couple of other things come to mind (naturally, after pushing >> 'send'): >>>>> Initialization will load/verify the microcode. That has to work. >>>>> >>>>> After setting RUN and the interrupt enables, expect base-in and >>>>> control-in command to establish the DUP CSR address, buffers, line >>> mode/enable. >>>>> These require that the KMC respond to KMCRQI by initiating an A >>>>> vector interrupt. >>>>> >>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) >>>>> and bit >>>> clear >>>>> (BCIO) instructions that also touch the KMC. >>>>> >>>>> For better directed hints, I'd need more detail on what is and >>>>> isn't >>>> happening. >>>>> This communication may not represent my employer's views, if any, >>>>> on the matters discussed. >>>>> >>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>> Sent: 08 May 2013 01:02 >>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>>> From: "Robert Jarratt" >>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can >>>>>>>> see that it is trying to get the Microprocessor to do something >>>>>>>> and read back some values, but I don't know what values it wants >>>>>>>> to get and so it reports: >>>>>>> Hi, Rob, >>>>>>> >>>>>>> http://pdp-10.trailing- >>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>> l >>>>>>> >>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>> >>>>>>> >>>>>>> Rich _______________________________________________ >>>>>>> Simh mailing list >>>>>>> Simh at trailing-edge.com >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>> I am making some progress with getting the KMC/DUP emulation >>> working >>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which >>>>>> is the interrupts to tell the OS that the KMC has processed a > buffer. >>>>>> The OS sets the interrupt enable bit and when I have something to >>>>>> report to the OS I set the relevant interrupt bit. However, >>>>>> nothing happens when I do that. I am wondering if I have the right >>>>>> interrupt bit? I am using bits 8 and 9 (decimal). >>>>>> >>>>>> I am not sure how to find out which bit I should be setting. >>>>>> >>>>>> Can anyone help? >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>> _______________________________________________ >>>>>> Simh mailing list >>>>>> Simh at trailing-edge.com >>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 12:36:32 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 17:36:32 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198F73E.803@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> Message-ID: <037901ce54af$0b17c440$21474cc0$@ntlworld.com> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, not an A, so that would make sense. I have A vectored at bit 8, and B at bit 9. Are you referring to this code: ;HERE FOR INPUT INTERRUPTS KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG MOVEI 17,KMCACS ;BUILD BLT POINTER BLT 17,KMCACS+16 ;SAVE REST OF REGS MOVE P,[-40,,KMCIPL] ;SET UP STACK MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW RDIO T2,BSEL2(T4) ;GET RDI FLAG MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? TRNN T2,KMCRDI ;AND IS IT READY ? BUG (KMCIII,<,>) CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT FLAG CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY If so, then despite the fact that I am setting bit 9 in the interrupt request, it seems to be going to the A interrupt handler. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 17:01 > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > The bugcheck is saying that the RDYO is set, but not RDYI on an A interrupt. > (KMCRDI is 20; RDO is 200) > > RDYO should always go to IVB; RDYI to IVA. > > Since we took an IVA interrupt, the driver thinks its trying to give the KMC a > command, but the interrupt is going to the wrong vector since RDYI is not set. > So either you're generating an IVA but setting the wrong status bit, or > generating an Ivb event but not to the right vector. Or perhaps you have an > overrun - the interrupt has to be cleared when the drive clears the RDx bit. > > The data looks like a DDCMP start, less the CRCs. That indicates that a fair bit > of stuff is working; this is the data that the -10 provides to the KMC. > > Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and > data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > CRC errors are reported by control out bits. Since the KMC both adds on > transmit and removes/checks on receive, and you are running over an error- > checked transport, you can get away with not simulating this - unless you > want to interoperate with an interface that does add the CRCs. > > Even if the systems are cloned, the DDCMP layer should come up; you'll die > later when transport detects a duplicate DECnet node number. > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 19-May-13 11:01, Robert Jarratt wrote: > > What is curious now is that I have two instances (identical clones) running > > attempting to talk to each other. The first message one sends to the other > > crashes the OS: > > > > ********** > > *BUGHLT "KMCIII" AT 19-May-2013 15: > > *ADDITIONAL DATA: 000000172507, 000000000200 > > ********** > > > > The odd thing is that I have delivered the same data that was sent from the > > other end, so it should be valid data. > > > > The data is: 05 06 C0 00 00 01 > > > > That data does not seem to completely match the DDCMP spec I have, I > think > > some checksum is supposed to follow. Is that supposed to be added by the > KMC > > perhaps? > > > > I don't fully expect it to work because they are clones so would expect > some > > kind of error, but would not expect a crash, or am I wrong? > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Robert Jarratt > >> Sent: 19 May 2013 15:21 > >> To: 'Timothe Litt'; simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> I have made some progress. I realised that I did not have the interrupt > >> acknowledgement routines set up in the DIB. It is working a bit better > > now. > >> I have indeed seen some commands to read the ram and verify the > >> microcode, it does all this to check the KMC is working before enabling > > it. > >> This particular code has never (as far as I know) worked for the 11 or the > >> VAX. I wrote the DMC11 code for those. This code I am working with now > >> came from someone else and was written for the PDP1) for a much older > >> version of SIMH. > >> > >> Regards > >> > >> Rob > >> > >>> -----Original Message----- > >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >>> edge.com] On Behalf Of Timothe Litt > >>> Sent: 19 May 2013 14:54 > >>> To: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>>> I am pretty sure I am doing all the things you mention already > >>> Then I need a trace of what's happening to the registers, and what simh > >>> thinks it's doing with the interrupts. (It would be easiest to follow > >>> if you output both octal and decode the register names/fields, though > >>> I > >> can > >>> still think - slowly- in octal.) > >>> > >>> Also, I thought this code was working for the -11/VAX. If so, the > >>> basics > >> must > >>> be OK, though the drivers may well take a different approach to the > >> device. > >>> Received data should produce either a control-out (error, e.g. no > >>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. > >>> The > >> message > >>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>> > >>> Transmit done - also note that we ignore interrupts unless the 'last > >> buffer' bit > >>> is set. (The DDCMP header and data are in two BDL segments, and > >>> require two interrupts.) > >>> > >>> Finally, I'm not sure if you'll see it used, but there is code in the > >>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) > to > >>> force the microcontroller to execute several known instructions - to > >> access its > >>> data ram, registers & PC. This is primarily used to dump a KMC that > >>> halts > >> - it > >>> doesn't seem to be used when the built-in ucode is loaded. But some > >>> of these are also used to verify data ram at initialization. Failure > >>> to > >> verify will > >>> cause the device to be disabled. We can go down that path if you see > >> those > >>> bits being set in a trace. > >>> > >>> Look for KMCXCT calls in > >>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>> sources/kdpsrv.mac.html > >>> TOPS-10 doesn't do this. The microinstructions are defined in > >>> http://bitsavers.trailing- > >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>> nual.pdf > >>> >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>> 0Manual.pdf> > >>> The subset is pretty small - load address register, load/store > >>> indirect > >> (with > >>> increment), & branch. I think you ought to be able to crash simh if > >>> an unknown instruction is forced, including a branch to an address > >>> other than > >> 0. > >>> Ugly device, ugly driver. Sigh. > >>> > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>> Thanks Timothe, > >>>> > >>>> I am pretty sure I am doing all the things you mention already > >>>> (sorry I didn't make that clear), but I will check through > >>>> everything you have said, just in case I have missed something. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>>> edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 11:26 > >>>>> To: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> A couple of other things come to mind (naturally, after pushing > >> 'send'): > >>>>> Initialization will load/verify the microcode. That has to work. > >>>>> > >>>>> After setting RUN and the interrupt enables, expect base-in and > >>>>> control-in command to establish the DUP CSR address, buffers, line > >>> mode/enable. > >>>>> These require that the KMC respond to KMCRQI by initiating an A > >>>>> vector interrupt. > >>>>> > >>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) > >>>>> and bit > >>>> clear > >>>>> (BCIO) instructions that also touch the KMC. > >>>>> > >>>>> For better directed hints, I'd need more detail on what is and > >>>>> isn't > >>>> happening. > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>> Sent: 08 May 2013 01:02 > >>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>>> From: "Robert Jarratt" > >>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can > >>>>>>>> see that it is trying to get the Microprocessor to do something > >>>>>>>> and read back some values, but I don't know what values it wants > >>>>>>>> to get and so it reports: > >>>>>>> Hi, Rob, > >>>>>>> > >>>>>>> http://pdp-10.trailing- > >>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>> l > >>>>>>> > >>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>> > >>>>>>> > >>>>>>> Rich _______________________________________________ > >>>>>>> Simh mailing list > >>>>>>> Simh at trailing-edge.com > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>> I am making some progress with getting the KMC/DUP emulation > >>> working > >>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which > >>>>>> is the interrupts to tell the OS that the KMC has processed a > > buffer. > >>>>>> The OS sets the interrupt enable bit and when I have something to > >>>>>> report to the OS I set the relevant interrupt bit. However, > >>>>>> nothing happens when I do that. I am wondering if I have the right > >>>>>> interrupt bit? I am using bits 8 and 9 (decimal). > >>>>>> > >>>>>> I am not sure how to find out which bit I should be setting. > >>>>>> > >>>>>> Can anyone help? > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Simh mailing list > >>>>>> Simh at trailing-edge.com > >>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >> > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Sun May 19 13:01:01 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 13:01:01 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <037901ce54af$0b17c440$21474cc0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> Message-ID: <5199054D.2030909@ieee.org> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT "KMCIII". You need to tell simh what vector to use when you tell it about the pending interrupt. Most devices have only one vector. The KMC (and DMC/DMR) have 2. A is the (numerically) first; B is the second. So in the interrupt ack routine, you need to return VEC_KDP * kmcnumber or VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. (Or whatever symbol you used.) A should be generated by RDI; B by RDO. That will tell simh how to find the right service routine. IIRC, if both happen to be pending at the same time, A takes precedence. Without seeing the code, I can't be more explicit... Oh, be careful when you talk about bit numbers. The unibus is little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 12:36, Robert Jarratt wrote: > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, not an > A, so that would make sense. I have A vectored at bit 8, and B at bit 9. > > Are you referring to this code: > > ;HERE FOR INPUT INTERRUPTS > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > MOVEI 17,KMCACS ;BUILD BLT POINTER > BLT 17,KMCACS+16 ;SAVE REST OF REGS > MOVE P,[-40,,KMCIPL] ;SET UP STACK > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > RDIO T2,BSEL2(T4) ;GET RDI FLAG > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > TRNN T2,KMCRDI ;AND IS IT READY ? > BUG (KMCIII,<,>) << A interrupt with nothing in the driver queue, or RDI not set > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT FLAG << CSR BIT requesting an A interrupt > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request when driver queue empty > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > << the command is then removed from the driver queue and written to the KMC. The KMC << must clear RDI until it is ready to take the next command. (Note that otherwise if the queue depth >1, the << A interrupt will happen immediately. > If so, then despite the fact that I am setting bit 9 in the interrupt > request, it seems to be going to the A interrupt handler. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Timothe Litt >> Sent: 19 May 2013 17:01 >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > interrupt. >> (KMCRDI is 20; RDO is 200) >> >> RDYO should always go to IVB; RDYI to IVA. >> >> Since we took an IVA interrupt, the driver thinks its trying to give the > KMC a >> command, but the interrupt is going to the wrong vector since RDYI is not > set. >> So either you're generating an IVA but setting the wrong status bit, or >> generating an Ivb event but not to the right vector. Or perhaps you have > an >> overrun - the interrupt has to be cleared when the drive clears the RDx > bit. >> The data looks like a DDCMP start, less the CRCs. That indicates that a > fair bit >> of stuff is working; this is the data that the -10 provides to the KMC. >> >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >> CRC errors are reported by control out bits. Since the KMC both adds on >> transmit and removes/checks on receive, and you are running over an error- >> checked transport, you can get away with not simulating this - unless you >> want to interoperate with an interface that does add the CRCs. >> >> Even if the systems are cloned, the DDCMP layer should come up; you'll die >> later when transport detects a duplicate DECnet node number. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> On 19-May-13 11:01, Robert Jarratt wrote: >>> What is curious now is that I have two instances (identical clones) > running >>> attempting to talk to each other. The first message one sends to the > other >>> crashes the OS: >>> >>> ********** >>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>> *ADDITIONAL DATA: 000000172507, 000000000200 >>> ********** >>> >>> The odd thing is that I have delivered the same data that was sent from > the >>> other end, so it should be valid data. >>> >>> The data is: 05 06 C0 00 00 01 >>> >>> That data does not seem to completely match the DDCMP spec I have, I >> think >>> some checksum is supposed to follow. Is that supposed to be added by the >> KMC >>> perhaps? >>> >>> I don't fully expect it to work because they are clones so would expect >> some >>> kind of error, but would not expect a crash, or am I wrong? >>> >>> Regards >>> >>> Rob >>> >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Robert Jarratt >>>> Sent: 19 May 2013 15:21 >>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>> I have made some progress. I realised that I did not have the interrupt >>>> acknowledgement routines set up in the DIB. It is working a bit better >>> now. >>>> I have indeed seen some commands to read the ram and verify the >>>> microcode, it does all this to check the KMC is working before enabling >>> it. >>>> This particular code has never (as far as I know) worked for the 11 or > the >>>> VAX. I wrote the DMC11 code for those. This code I am working with now >>>> came from someone else and was written for the PDP1) for a much older >>>> version of SIMH. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 14:54 >>>>> To: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>>> I am pretty sure I am doing all the things you mention already >>>>> Then I need a trace of what's happening to the registers, and what > simh >>>>> thinks it's doing with the interrupts. (It would be easiest to > follow >>>>> if you output both octal and decode the register names/fields, though >>>>> I >>>> can >>>>> still think - slowly- in octal.) >>>>> >>>>> Also, I thought this code was working for the -11/VAX. If so, the >>>>> basics >>>> must >>>>> be OK, though the drivers may well take a different approach to the >>>> device. >>>>> Received data should produce either a control-out (error, e.g. no >>>>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. >>>>> The >>>> message >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>> >>>>> Transmit done - also note that we ignore interrupts unless the 'last >>>> buffer' bit >>>>> is set. (The DDCMP header and data are in two BDL segments, and >>>>> require two interrupts.) >>>>> >>>>> Finally, I'm not sure if you'll see it used, but there is code in the >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) >> to >>>>> force the microcontroller to execute several known instructions - to >>>> access its >>>>> data ram, registers & PC. This is primarily used to dump a KMC that >>>>> halts >>>> - it >>>>> doesn't seem to be used when the built-in ucode is loaded. But some >>>>> of these are also used to verify data ram at initialization. Failure >>>>> to >>>> verify will >>>>> cause the device to be disabled. We can go down that path if you see >>>> those >>>>> bits being set in a trace. >>>>> >>>>> Look for KMCXCT calls in >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>> sources/kdpsrv.mac.html >>>>> TOPS-10 doesn't do this. The microinstructions are defined in >>>>> http://bitsavers.trailing- >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>> nual.pdf >>>>> >>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>> 0Manual.pdf> >>>>> The subset is pretty small - load address register, load/store >>>>> indirect >>>> (with >>>>> increment), & branch. I think you ought to be able to crash simh if >>>>> an unknown instruction is forced, including a branch to an address >>>>> other than >>>> 0. >>>>> Ugly device, ugly driver. Sigh. >>>>> >>>>> >>>>> This communication may not represent my employer's views, if any, on >>>>> the matters discussed. >>>>> >>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>> Thanks Timothe, >>>>>> >>>>>> I am pretty sure I am doing all the things you mention already >>>>>> (sorry I didn't make that clear), but I will check through >>>>>> everything you have said, just in case I have missed something. >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >> bounces at trailing- >>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>> Sent: 19 May 2013 11:26 >>>>>>> To: simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> A couple of other things come to mind (naturally, after pushing >>>> 'send'): >>>>>>> Initialization will load/verify the microcode. That has to work. >>>>>>> >>>>>>> After setting RUN and the interrupt enables, expect base-in and >>>>>>> control-in command to establish the DUP CSR address, buffers, line >>>>> mode/enable. >>>>>>> These require that the KMC respond to KMCRQI by initiating an A >>>>>>> vector interrupt. >>>>>>> >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) >>>>>>> and bit >>>>>> clear >>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>> >>>>>>> For better directed hints, I'd need more detail on what is and >>>>>>> isn't >>>>>> happening. >>>>>>> This communication may not represent my employer's views, if any, >>>>>>> on the matters discussed. >>>>>>> >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>> >>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can >>>>>>>>>> see that it is trying to get the Microprocessor to do something >>>>>>>>>> and read back some values, but I don't know what values it wants >>>>>>>>>> to get and so it reports: >>>>>>>>> Hi, Rob, >>>>>>>>> >>>>>>>>> http://pdp-10.trailing- >>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>> l >>>>>>>>> >>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>> >>>>>>>>> >>>>>>>>> Rich _______________________________________________ >>>>>>>>> Simh mailing list >>>>>>>>> Simh at trailing-edge.com >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>> I am making some progress with getting the KMC/DUP emulation >>>>> working >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which >>>>>>>> is the interrupts to tell the OS that the KMC has processed a >>> buffer. >>>>>>>> The OS sets the interrupt enable bit and when I have something to >>>>>>>> report to the OS I set the relevant interrupt bit. However, >>>>>>>> nothing happens when I do that. I am wondering if I have the right >>>>>>>> interrupt bit? I am using bits 8 and 9 (decimal). >>>>>>>> >>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>> >>>>>>>> Can anyone help? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Rob >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Simh mailing list >>>>>>>> Simh at trailing-edge.com >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 16:01:04 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 21:01:04 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5199054D.2030909@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> Message-ID: <03b401ce54cb$99044050$cb0cc0f0$@ntlworld.com> Thanks! There was a bug in my interrupt acknowledge routine. With that fixed the interrupts now seem to be working OK. I have made progress, with the two clones talking to each other I get this now: ******************** *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 *BAD DDCMP HEADER *ADDITIONAL DATA: 746314746314, 746314777777 ******************** I am going to have to re-learn MACRO to work out why it is failing. The code I see has two jumps to BUMHDR, I can't work out what the first one means, the second seems to be checking the first byte, which being 0x06 should be OK, so it is probably the first condition that is failing. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 18:01 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > "KMCIII". > > You need to tell simh what vector to use when you tell it about the pending > interrupt. Most devices have only one vector. The KMC (and > DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. > (Or whatever symbol you used.) A should be generated by RDI; B by RDO. > > That will tell simh how to find the right service routine. > > IIRC, if both happen to be pending at the same time, A takes precedence. > > Without seeing the code, I can't be more explicit... > > Oh, be careful when you talk about bit numbers. The unibus is little-endian > (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 12:36, Robert Jarratt wrote: > > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > > not an A, so that would make sense. I have A vectored at bit 8, and B at bit > 9. > > > > Are you referring to this code: > > > > ;HERE FOR INPUT INTERRUPTS > > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > MOVEI 17,KMCACS ;BUILD BLT POINTER > > BLT 17,KMCACS+16 ;SAVE REST OF REGS > > MOVE P,[-40,,KMCIPL] ;SET UP STACK > > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > RDIO T2,BSEL2(T4) ;GET RDI FLAG > > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > TRNN T2,KMCRDI ;AND IS IT READY ? > > BUG (KMCIII,<,>) << A interrupt with nothing in the > driver queue, or RDI not set > > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > FLAG << CSR BIT requesting an A interrupt > > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > when driver queue empty > > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > << the command is then removed from the driver queue and written to > > the KMC. The KMC > << must clear RDI until it is ready to take the next command. (Note that > otherwise if the queue depth >1, the << A interrupt will happen > immediately. > > If so, then despite the fact that I am setting bit 9 in the interrupt > > request, it seems to be going to the A interrupt handler. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Timothe Litt > >> Sent: 19 May 2013 17:01 > >> Cc: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > > interrupt. > >> (KMCRDI is 20; RDO is 200) > >> > >> RDYO should always go to IVB; RDYI to IVA. > >> > >> Since we took an IVA interrupt, the driver thinks its trying to give > >> the > > KMC a > >> command, but the interrupt is going to the wrong vector since RDYI is > >> not > > set. > >> So either you're generating an IVA but setting the wrong status bit, > >> or generating an Ivb event but not to the right vector. Or perhaps > >> you have > > an > >> overrun - the interrupt has to be cleared when the drive clears the > >> RDx > > bit. > >> The data looks like a DDCMP start, less the CRCs. That indicates > >> that a > > fair bit > >> of stuff is working; this is the data that the -10 provides to the KMC. > >> > >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and > >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >> CRC errors are reported by control out bits. Since the KMC both adds > >> on transmit and removes/checks on receive, and you are running over > >> an error- checked transport, you can get away with not simulating > >> this - unless you want to interoperate with an interface that does add the > CRCs. > >> > >> Even if the systems are cloned, the DDCMP layer should come up; > >> you'll die later when transport detects a duplicate DECnet node number. > >> > >> > >> This communication may not represent my employer's views, if any, on > >> the matters discussed. > >> > >> On 19-May-13 11:01, Robert Jarratt wrote: > >>> What is curious now is that I have two instances (identical clones) > > running > >>> attempting to talk to each other. The first message one sends to the > > other > >>> crashes the OS: > >>> > >>> ********** > >>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>> ********** > >>> > >>> The odd thing is that I have delivered the same data that was sent > >>> from > > the > >>> other end, so it should be valid data. > >>> > >>> The data is: 05 06 C0 00 00 01 > >>> > >>> That data does not seem to completely match the DDCMP spec I have, I > >> think > >>> some checksum is supposed to follow. Is that supposed to be added by > >>> the > >> KMC > >>> perhaps? > >>> > >>> I don't fully expect it to work because they are clones so would > >>> expect > >> some > >>> kind of error, but would not expect a crash, or am I wrong? > >>> > >>> Regards > >>> > >>> Rob > >>> > >>>> -----Original Message----- > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>> edge.com] On Behalf Of Robert Jarratt > >>>> Sent: 19 May 2013 15:21 > >>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>> > >>>> I have made some progress. I realised that I did not have the > >>>> interrupt acknowledgement routines set up in the DIB. It is working > >>>> a bit better > >>> now. > >>>> I have indeed seen some commands to read the ram and verify the > >>>> microcode, it does all this to check the KMC is working before > >>>> enabling > >>> it. > >>>> This particular code has never (as far as I know) worked for the 11 > >>>> or > > the > >>>> VAX. I wrote the DMC11 code for those. This code I am working with > >>>> now came from someone else and was written for the PDP1) for a > much > >>>> older version of SIMH. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com > >>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 14:54 > >>>>> To: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>>> I am pretty sure I am doing all the things you mention already > >>>>> Then I need a trace of what's happening to the registers, and what > > simh > >>>>> thinks it's doing with the interrupts. (It would be easiest to > > follow > >>>>> if you output both octal and decode the register names/fields, > >>>>> though I > >>>> can > >>>>> still think - slowly- in octal.) > >>>>> > >>>>> Also, I thought this code was working for the -11/VAX. If so, the > >>>>> basics > >>>> must > >>>>> be OK, though the drivers may well take a different approach to > >>>>> the > >>>> device. > >>>>> Received data should produce either a control-out (error, e.g. no > >>>>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. > >>>>> The > >>>> message > >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>> > >>>>> Transmit done - also note that we ignore interrupts unless the > >>>>> 'last > >>>> buffer' bit > >>>>> is set. (The DDCMP header and data are in two BDL segments, and > >>>>> require two interrupts.) > >>>>> > >>>>> Finally, I'm not sure if you'll see it used, but there is code in > >>>>> the > >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP > >>>>> 400) > >> to > >>>>> force the microcontroller to execute several known instructions - > >>>>> to > >>>> access its > >>>>> data ram, registers & PC. This is primarily used to dump a KMC > >>>>> that halts > >>>> - it > >>>>> doesn't seem to be used when the built-in ucode is loaded. But > >>>>> some of these are also used to verify data ram at initialization. > >>>>> Failure to > >>>> verify will > >>>>> cause the device to be disabled. We can go down that path if you > >>>>> see > >>>> those > >>>>> bits being set in a trace. > >>>>> > >>>>> Look for KMCXCT calls in > >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>> sources/kdpsrv.mac.html > >>>>> TOPS-10 doesn't do this. The microinstructions are defined in > >>>>> http://bitsavers.trailing- > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>> nual.pdf > >>>>> >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>> 0Manual.pdf> > >>>>> The subset is pretty small - load address register, load/store > >>>>> indirect > >>>> (with > >>>>> increment), & branch. I think you ought to be able to crash simh > >>>>> if an unknown instruction is forced, including a branch to an > >>>>> address other than > >>>> 0. > >>>>> Ugly device, ugly driver. Sigh. > >>>>> > >>>>> > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>> Thanks Timothe, > >>>>>> > >>>>>> I am pretty sure I am doing all the things you mention already > >>>>>> (sorry I didn't make that clear), but I will check through > >>>>>> everything you have said, just in case I have missed something. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>> Sent: 19 May 2013 11:26 > >>>>>>> To: simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>> A couple of other things come to mind (naturally, after pushing > >>>> 'send'): > >>>>>>> Initialization will load/verify the microcode. That has to work. > >>>>>>> > >>>>>>> After setting RUN and the interrupt enables, expect base-in and > >>>>>>> control-in command to establish the DUP CSR address, buffers, > >>>>>>> line > >>>>> mode/enable. > >>>>>>> These require that the KMC respond to KMCRQI by initiating an A > >>>>>>> vector interrupt. > >>>>>>> > >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>> (BSIO) and bit > >>>>>> clear > >>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>> > >>>>>>> For better directed hints, I'd need more detail on what is and > >>>>>>> isn't > >>>>>> happening. > >>>>>>> This communication may not represent my employer's views, if > >>>>>>> any, on the matters discussed. > >>>>>>> > >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>> bounces at trailing- > >>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>> > >>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at > >>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? > >>>>>>>>>> I can see that it is trying to get the Microprocessor to do > >>>>>>>>>> something and read back some values, but I don't know what > >>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>> Hi, Rob, > >>>>>>>>> > >>>>>>>>> http://pdp-10.trailing- > >>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>> l > >>>>>>>>> > >>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Rich > _______________________________________________ > >>>>>>>>> Simh mailing list > >>>>>>>>> Simh at trailing-edge.com > >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>> I am making some progress with getting the KMC/DUP emulation > >>>>> working > >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > >>>>>>>> which is the interrupts to tell the OS that the KMC has > >>>>>>>> processed a > >>> buffer. > >>>>>>>> The OS sets the interrupt enable bit and when I have something > >>>>>>>> to report to the OS I set the relevant interrupt bit. However, > >>>>>>>> nothing happens when I do that. I am wondering if I have the > >>>>>>>> right interrupt bit? I am using bits 8 and 9 (decimal). > >>>>>>>> > >>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>> > >>>>>>>> Can anyone help? > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> Rob > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Simh mailing list > >>>>>>>> Simh at trailing-edge.com > >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>> _______________________________________________ > >>>> Simh mailing list > >>>> Simh at trailing-edge.com > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 19 16:06:15 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 21:06:15 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> Message-ID: <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> Oops, meant to say the first byte sent is 0x05. > -----Original Message----- > From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > Sent: 19 May 2013 21:01 > To: 'Timothe Litt'; 'simh at trailing-edge.com' > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Thanks! There was a bug in my interrupt acknowledge routine. With that > fixed the interrupts now seem to be working OK. I have made progress, with > the two clones talking to each other I get this now: > > > ******************** > *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > *BAD DDCMP HEADER > *ADDITIONAL DATA: 746314746314, 746314777777 > ******************** > > I am going to have to re-learn MACRO to work out why it is failing. The code I > see has two jumps to BUMHDR, I can't work out what the first one means, > the second seems to be checking the first byte, which being 0x06 should be > OK, so it is probably the first condition that is failing. > > Regards > > Rob > > > > -----Original Message----- > > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > edge.com] On Behalf Of Timothe Litt > > Sent: 19 May 2013 18:01 > > To: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > > "KMCIII". > > > > You need to tell simh what vector to use when you tell it about the > > pending interrupt. Most devices have only one vector. The KMC (and > > DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > > the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > > VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. > > (Or whatever symbol you used.) A should be generated by RDI; B by RDO. > > > > That will tell simh how to find the right service routine. > > > > IIRC, if both happen to be pending at the same time, A takes precedence. > > > > Without seeing the code, I can't be more explicit... > > > > Oh, be careful when you talk about bit numbers. The unibus is > > little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 12:36, Robert Jarratt wrote: > > > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > > > not an A, so that would make sense. I have A vectored at bit 8, and > > > B at bit > > 9. > > > > > > Are you referring to this code: > > > > > > ;HERE FOR INPUT INTERRUPTS > > > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > > MOVEI 17,KMCACS ;BUILD BLT POINTER > > > BLT 17,KMCACS+16 ;SAVE REST OF REGS > > > MOVE P,[-40,,KMCIPL] ;SET UP STACK > > > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > > RDIO T2,BSEL2(T4) ;GET RDI FLAG > > > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > > TRNN T2,KMCRDI ;AND IS IT READY ? > > > BUG (KMCIII,<,>) << A interrupt with nothing in the > > driver queue, or RDI not set > > > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > > FLAG << CSR BIT requesting an A interrupt > > > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > > when driver queue empty > > > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > > << the command is then removed from the driver queue and written to > > > the KMC. The KMC > > << must clear RDI until it is ready to take the next command. (Note > > that otherwise if the queue depth >1, the << A interrupt will happen > > immediately. > > > If so, then despite the fact that I am setting bit 9 in the > > > interrupt request, it seems to be going to the A interrupt handler. > > > > > > Regards > > > > > > Rob > > > > > >> -----Original Message----- > > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > >> edge.com] On Behalf Of Timothe Litt > > >> Sent: 19 May 2013 17:01 > > >> Cc: simh at trailing-edge.com > > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > > > interrupt. > > >> (KMCRDI is 20; RDO is 200) > > >> > > >> RDYO should always go to IVB; RDYI to IVA. > > >> > > >> Since we took an IVA interrupt, the driver thinks its trying to > > >> give the > > > KMC a > > >> command, but the interrupt is going to the wrong vector since RDYI > > >> is not > > > set. > > >> So either you're generating an IVA but setting the wrong status > > >> bit, or generating an Ivb event but not to the right vector. Or > > >> perhaps you have > > > an > > >> overrun - the interrupt has to be cleared when the drive clears the > > >> RDx > > > bit. > > >> The data looks like a DDCMP start, less the CRCs. That indicates > > >> that a > > > fair bit > > >> of stuff is working; this is the data that the -10 provides to the KMC. > > >> > > >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > > >> and > > >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > > >> CRC errors are reported by control out bits. Since the KMC both > > >> adds on transmit and removes/checks on receive, and you are running > > >> over an error- checked transport, you can get away with not > > >> simulating this - unless you want to interoperate with an interface > > >> that does add the > > CRCs. > > >> > > >> Even if the systems are cloned, the DDCMP layer should come up; > > >> you'll die later when transport detects a duplicate DECnet node number. > > >> > > >> > > >> This communication may not represent my employer's views, if any, > > >> on the matters discussed. > > >> > > >> On 19-May-13 11:01, Robert Jarratt wrote: > > >>> What is curious now is that I have two instances (identical > > >>> clones) > > > running > > >>> attempting to talk to each other. The first message one sends to > > >>> the > > > other > > >>> crashes the OS: > > >>> > > >>> ********** > > >>> *BUGHLT "KMCIII" AT 19-May-2013 15: > > >>> *ADDITIONAL DATA: 000000172507, 000000000200 > > >>> ********** > > >>> > > >>> The odd thing is that I have delivered the same data that was sent > > >>> from > > > the > > >>> other end, so it should be valid data. > > >>> > > >>> The data is: 05 06 C0 00 00 01 > > >>> > > >>> That data does not seem to completely match the DDCMP spec I have, > > >>> I > > >> think > > >>> some checksum is supposed to follow. Is that supposed to be added > > >>> by the > > >> KMC > > >>> perhaps? > > >>> > > >>> I don't fully expect it to work because they are clones so would > > >>> expect > > >> some > > >>> kind of error, but would not expect a crash, or am I wrong? > > >>> > > >>> Regards > > >>> > > >>> Rob > > >>> > > >>>> -----Original Message----- > > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>> edge.com] On Behalf Of Robert Jarratt > > >>>> Sent: 19 May 2013 15:21 > > >>>> To: 'Timothe Litt'; simh at trailing-edge.com > > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>> > > >>>> I have made some progress. I realised that I did not have the > > >>>> interrupt acknowledgement routines set up in the DIB. It is > > >>>> working a bit better > > >>> now. > > >>>> I have indeed seen some commands to read the ram and verify the > > >>>> microcode, it does all this to check the KMC is working before > > >>>> enabling > > >>> it. > > >>>> This particular code has never (as far as I know) worked for the > > >>>> 11 or > > > the > > >>>> VAX. I wrote the DMC11 code for those. This code I am working > > >>>> with now came from someone else and was written for the PDP1) for > > >>>> a > > much > > >>>> older version of SIMH. > > >>>> > > >>>> Regards > > >>>> > > >>>> Rob > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: simh-bounces at trailing-edge.com > > >>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe > > >>>>> Litt > > >>>>> Sent: 19 May 2013 14:54 > > >>>>> To: simh at trailing-edge.com > > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>> Then I need a trace of what's happening to the registers, and > > >>>>> what > > > simh > > >>>>> thinks it's doing with the interrupts. (It would be easiest to > > > follow > > >>>>> if you output both octal and decode the register names/fields, > > >>>>> though I > > >>>> can > > >>>>> still think - slowly- in octal.) > > >>>>> > > >>>>> Also, I thought this code was working for the -11/VAX. If so, > > >>>>> the basics > > >>>> must > > >>>>> be OK, though the drivers may well take a different approach to > > >>>>> the > > >>>> device. > > >>>>> Received data should produce either a control-out (error, e.g. > > >>>>> no buffer available or DSR change or NXM...) or a buffer-out B > interrupt. > > >>>>> The > > >>>> message > > >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > > >>>>> > > >>>>> Transmit done - also note that we ignore interrupts unless the > > >>>>> 'last > > >>>> buffer' bit > > >>>>> is set. (The DDCMP header and data are in two BDL segments, and > > >>>>> require two interrupts.) > > >>>>> > > >>>>> Finally, I'm not sure if you'll see it used, but there is code > > >>>>> in the > > >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP > > >>>>> 400) > > >> to > > >>>>> force the microcontroller to execute several known instructions > > >>>>> - to > > >>>> access its > > >>>>> data ram, registers & PC. This is primarily used to dump a KMC > > >>>>> that halts > > >>>> - it > > >>>>> doesn't seem to be used when the built-in ucode is loaded. But > > >>>>> some of these are also used to verify data ram at initialization. > > >>>>> Failure to > > >>>> verify will > > >>>>> cause the device to be disabled. We can go down that path if > > >>>>> you see > > >>>> those > > >>>>> bits being set in a trace. > > >>>>> > > >>>>> Look for KMCXCT calls in > > >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > >>>>> sources/kdpsrv.mac.html > > >>>>> TOPS-10 doesn't do this. The microinstructions are defined in > > >>>>> http://bitsavers.trailing- > > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > >>>>> nual.pdf > > >>>>> > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > >>>>> 0Manual.pdf> > > >>>>> The subset is pretty small - load address register, load/store > > >>>>> indirect > > >>>> (with > > >>>>> increment), & branch. I think you ought to be able to crash > > >>>>> simh if an unknown instruction is forced, including a branch to > > >>>>> an address other than > > >>>> 0. > > >>>>> Ugly device, ugly driver. Sigh. > > >>>>> > > >>>>> > > >>>>> This communication may not represent my employer's views, if > > >>>>> any, on the matters discussed. > > >>>>> > > >>>>> On 19-May-13 07:42, Robert Jarratt wrote: > > >>>>>> Thanks Timothe, > > >>>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>>> (sorry I didn't make that clear), but I will check through > > >>>>>> everything you have said, just in case I have missed something. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >> bounces at trailing- > > >>>>>>> edge.com] On Behalf Of Timothe Litt > > >>>>>>> Sent: 19 May 2013 11:26 > > >>>>>>> To: simh at trailing-edge.com > > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>> > > >>>>>>> A couple of other things come to mind (naturally, after > > >>>>>>> pushing > > >>>> 'send'): > > >>>>>>> Initialization will load/verify the microcode. That has to work. > > >>>>>>> > > >>>>>>> After setting RUN and the interrupt enables, expect base-in > > >>>>>>> and control-in command to establish the DUP CSR address, > > >>>>>>> buffers, line > > >>>>> mode/enable. > > >>>>>>> These require that the KMC respond to KMCRQI by initiating an > > >>>>>>> A vector interrupt. > > >>>>>>> > > >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > > >>>>>>> (BSIO) and bit > > >>>>>> clear > > >>>>>>> (BCIO) instructions that also touch the KMC. > > >>>>>>> > > >>>>>>> For better directed hints, I'd need more detail on what is and > > >>>>>>> isn't > > >>>>>> happening. > > >>>>>>> This communication may not represent my employer's views, if > > >>>>>>> any, on the matters discussed. > > >>>>>>> > > >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>> bounces at trailing- > > >>>>>>>>> edge.com] On Behalf Of Rich Alderson > > >>>>>>>>> Sent: 08 May 2013 01:02 > > >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>>> > > >>>>>>>>>> From: "Robert Jarratt" > > >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at > > >>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? > > >>>>>>>>>> I can see that it is trying to get the Microprocessor to do > > >>>>>>>>>> something and read back some values, but I don't know what > > >>>>>>>>>> values it wants to get and so it reports: > > >>>>>>>>> Hi, Rob, > > >>>>>>>>> > > >>>>>>>>> http://pdp-10.trailing- > > >>>>> edge.com/tops20v41_monitor_sources/index.htm > > >>>>>>>>> l > > >>>>>>>>> > > >>>>>>>>> You want the file KDPSRV.MAC in that directory. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Rich > > _______________________________________________ > > >>>>>>>>> Simh mailing list > > >>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>>> I am making some progress with getting the KMC/DUP > emulation > > >>>>> working > > >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > > >>>>>>>> which is the interrupts to tell the OS that the KMC has > > >>>>>>>> processed a > > >>> buffer. > > >>>>>>>> The OS sets the interrupt enable bit and when I have > > >>>>>>>> something to report to the OS I set the relevant interrupt > > >>>>>>>> bit. However, nothing happens when I do that. I am wondering > > >>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 (decimal). > > >>>>>>>> > > >>>>>>>> I am not sure how to find out which bit I should be setting. > > >>>>>>>> > > >>>>>>>> Can anyone help? > > >>>>>>>> > > >>>>>>>> Regards > > >>>>>>>> > > >>>>>>>> Rob > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Simh mailing list > > >>>>>>>> Simh at trailing-edge.com > > >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>> _______________________________________________ > > >>>> Simh mailing list > > >>>> Simh at trailing-edge.com > > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > From litt at ieee.org Sun May 19 16:40:57 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 16:40:57 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> Message-ID: <519938D9.1010209@ieee.org> This is progress. Looks to me like the data isn't being stored properly. The ADDITIONAL DATA is the first 8 bytes of the data buffer. The SKIPL says the sign bit is set (which it is in 7463...). That's not possible. So I suspect you're not writing the data thru the UBA map correctly. Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit words packed into 18-bit 1/2 words. This looks like: /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE / /-- The ENQ goes here / / -- The START goes here ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 Since 00 is constant, the first digit can't be > 1. 7 mumble is. Thus for 05 06 (ENQ START), we should see something like 3005,,... in the first word. (5 + 6 << 8) Also, you need to map the UBA address to PDP-10 memory (which you seem to be doing for reads). This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 16:06, Robert Jarratt wrote: > Oops, meant to say the first byte sent is 0x05. > >> -----Original Message----- >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >> Sent: 19 May 2013 21:01 >> To: 'Timothe Litt'; 'simh at trailing-edge.com' >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> Thanks! There was a bug in my interrupt acknowledge routine. With that >> fixed the interrupts now seem to be working OK. I have made progress, with >> the two clones talking to each other I get this now: >> >> >> ******************** >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >> *BAD DDCMP HEADER >> *ADDITIONAL DATA: 746314746314, 746314777777 >> ******************** >> >> I am going to have to re-learn MACRO to work out why it is failing. The > code I >> see has two jumps to BUMHDR, I can't work out what the first one means, >> the second seems to be checking the first byte, which being 0x06 should be >> OK, so it is probably the first condition that is failing. >> >> Regards >> >> Rob >> >> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>> edge.com] On Behalf Of Timothe Litt >>> Sent: 19 May 2013 18:01 >>> To: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT >>> "KMCIII". >>> >>> You need to tell simh what vector to use when you tell it about the >>> pending interrupt. Most devices have only one vector. The KMC (and >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So in >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber or >>> VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. >>> (Or whatever symbol you used.) A should be generated by RDI; B by RDO. >>> >>> That will tell simh how to find the right service routine. >>> >>> IIRC, if both happen to be pending at the same time, A takes precedence. >>> >>> Without seeing the code, I can't be more explicit... >>> >>> Oh, be careful when you talk about bit numbers. The unibus is >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 12:36, Robert Jarratt wrote: >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, >>>> not an A, so that would make sense. I have A vectored at bit 8, and >>>> B at bit >>> 9. >>>> Are you referring to this code: >>>> >>>> ;HERE FOR INPUT INTERRUPTS >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? >>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the >>> driver queue, or RDI not set >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT >>> FLAG << CSR BIT requesting an A interrupt >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request >>> when driver queue empty >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY >>>> << the command is then removed from the driver queue and written to >>>> the KMC. The KMC >>> << must clear RDI until it is ready to take the next command. (Note >>> that otherwise if the queue depth >1, the << A interrupt will happen >>> immediately. >>>> If so, then despite the fact that I am setting bit 9 in the >>>> interrupt request, it seems to be going to the A interrupt handler. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 17:01 >>>>> Cc: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an A >>>> interrupt. >>>>> (KMCRDI is 20; RDO is 200) >>>>> >>>>> RDYO should always go to IVB; RDYI to IVA. >>>>> >>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>> give the >>>> KMC a >>>>> command, but the interrupt is going to the wrong vector since RDYI >>>>> is not >>>> set. >>>>> So either you're generating an IVA but setting the wrong status >>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>> perhaps you have >>>> an >>>>> overrun - the interrupt has to be cleared when the drive clears the >>>>> RDx >>>> bit. >>>>> The data looks like a DDCMP start, less the CRCs. That indicates >>>>> that a >>>> fair bit >>>>> of stuff is working; this is the data that the -10 provides to the > KMC. >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header >>>>> and >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >>>>> CRC errors are reported by control out bits. Since the KMC both >>>>> adds on transmit and removes/checks on receive, and you are running >>>>> over an error- checked transport, you can get away with not >>>>> simulating this - unless you want to interoperate with an interface >>>>> that does add the >>> CRCs. >>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>> you'll die later when transport detects a duplicate DECnet node > number. >>>>> >>>>> This communication may not represent my employer's views, if any, >>>>> on the matters discussed. >>>>> >>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>> What is curious now is that I have two instances (identical >>>>>> clones) >>>> running >>>>>> attempting to talk to each other. The first message one sends to >>>>>> the >>>> other >>>>>> crashes the OS: >>>>>> >>>>>> ********** >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>> ********** >>>>>> >>>>>> The odd thing is that I have delivered the same data that was sent >>>>>> from >>>> the >>>>>> other end, so it should be valid data. >>>>>> >>>>>> The data is: 05 06 C0 00 00 01 >>>>>> >>>>>> That data does not seem to completely match the DDCMP spec I have, >>>>>> I >>>>> think >>>>>> some checksum is supposed to follow. Is that supposed to be added >>>>>> by the >>>>> KMC >>>>>> perhaps? >>>>>> >>>>>> I don't fully expect it to work because they are clones so would >>>>>> expect >>>>> some >>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>> Sent: 19 May 2013 15:21 >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> I have made some progress. I realised that I did not have the >>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>> working a bit better >>>>>> now. >>>>>>> I have indeed seen some commands to read the ram and verify the >>>>>>> microcode, it does all this to check the KMC is working before >>>>>>> enabling >>>>>> it. >>>>>>> This particular code has never (as far as I know) worked for the >>>>>>> 11 or >>>> the >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>> with now came from someone else and was written for the PDP1) for >>>>>>> a >>> much >>>>>>> older version of SIMH. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe >>>>>>>> Litt >>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>> To: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>>> I am pretty sure I am doing all the things you mention already >>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>> what >>>> simh >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to >>>> follow >>>>>>>> if you output both octal and decode the register names/fields, >>>>>>>> though I >>>>>>> can >>>>>>>> still think - slowly- in octal.) >>>>>>>> >>>>>>>> Also, I thought this code was working for the -11/VAX. If so, >>>>>>>> the basics >>>>>>> must >>>>>>>> be OK, though the drivers may well take a different approach to >>>>>>>> the >>>>>>> device. >>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out B >> interrupt. >>>>>>>> The >>>>>>> message >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>> >>>>>>>> Transmit done - also note that we ignore interrupts unless the >>>>>>>> 'last >>>>>>> buffer' bit >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, and >>>>>>>> require two interrupts.) >>>>>>>> >>>>>>>> Finally, I'm not sure if you'll see it used, but there is code >>>>>>>> in the >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP >>>>>>>> 400) >>>>> to >>>>>>>> force the microcontroller to execute several known instructions >>>>>>>> - to >>>>>>> access its >>>>>>>> data ram, registers & PC. This is primarily used to dump a KMC >>>>>>>> that halts >>>>>>> - it >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. But >>>>>>>> some of these are also used to verify data ram at initialization. >>>>>>>> Failure to >>>>>>> verify will >>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>> you see >>>>>>> those >>>>>>>> bits being set in a trace. >>>>>>>> >>>>>>>> Look for KMCXCT calls in >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>> sources/kdpsrv.mac.html >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined in >>>>>>>> http://bitsavers.trailing- >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>> nual.pdf >>>>>>>> >>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>> 0Manual.pdf> >>>>>>>> The subset is pretty small - load address register, load/store >>>>>>>> indirect >>>>>>> (with >>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>> simh if an unknown instruction is forced, including a branch to >>>>>>>> an address other than >>>>>>> 0. >>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>> >>>>>>>> >>>>>>>> This communication may not represent my employer's views, if >>>>>>>> any, on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>> Thanks Timothe, >>>>>>>>> >>>>>>>>> I am pretty sure I am doing all the things you mention already >>>>>>>>> (sorry I didn't make that clear), but I will check through >>>>>>>>> everything you have said, just in case I have missed something. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>> pushing >>>>>>> 'send'): >>>>>>>>>> Initialization will load/verify the microcode. That has to > work. >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in >>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>> buffers, line >>>>>>>> mode/enable. >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating an >>>>>>>>>> A vector interrupt. >>>>>>>>>> >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>> (BSIO) and bit >>>>>>>>> clear >>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>> >>>>>>>>>> For better directed hints, I'd need more detail on what is and >>>>>>>>>> isn't >>>>>>>>> happening. >>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>> any, on the matters discussed. >>>>>>>>>> >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>> >>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to do >>>>>>>>>>>>> something and read back some values, but I don't know what >>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>> >>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>> l >>>>>>>>>>>> >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Rich >>> _______________________________________________ >>>>>>>>>>>> Simh mailing list >>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>> I am making some progress with getting the KMC/DUP >> emulation >>>>>>>> working >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, >>>>>>>>>>> which is the interrupts to tell the OS that the KMC has >>>>>>>>>>> processed a >>>>>> buffer. >>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>> bit. However, nothing happens when I do that. I am wondering >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). >>>>>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>>>>> >>>>>>>>>>> Can anyone help? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Rob >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Simh mailing list >>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>> _______________________________________________ >>>>>>> Simh mailing list >>>>>>> Simh at trailing-edge.com >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 17:46:44 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 22:46:44 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <519938D9.1010209@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> Message-ID: <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> Thanks, that sounds likely, I will check how I am writing to memory. Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 19 May 2013 21:41 > To: Robert Jarratt > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > This is progress. Looks to me like the data isn't being stored properly. > > The ADDITIONAL DATA is the first 8 bytes of the data buffer. The SKIPL > says the sign bit is set (which it is in 7463...). > That's not possible. > > So I suspect you're not writing the data thru the UBA map correctly. > > Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > words packed into 18-bit 1/2 words. > This looks like: > > /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > / /-- The ENQ goes here > / / -- The START goes here > ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 > ! 00 ! byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > > Since 00 is constant, the first digit can't be > 1. 7 mumble is. > > Thus for 05 06 (ENQ START), we should see something like 3005,,... in > the first word. > (5 + 6 << 8) > > Also, you need to map the UBA address to PDP-10 memory (which you seem > to be doing for reads). > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 19-May-13 16:06, Robert Jarratt wrote: > > Oops, meant to say the first byte sent is 0x05. > > > >> -----Original Message----- > >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > >> Sent: 19 May 2013 21:01 > >> To: 'Timothe Litt'; 'simh at trailing-edge.com' > >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> Thanks! There was a bug in my interrupt acknowledge routine. With that > >> fixed the interrupts now seem to be working OK. I have made progress, > with > >> the two clones talking to each other I get this now: > >> > >> > >> ******************** > >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > >> *BAD DDCMP HEADER > >> *ADDITIONAL DATA: 746314746314, 746314777777 > >> ******************** > >> > >> I am going to have to re-learn MACRO to work out why it is failing. The > > code I > >> see has two jumps to BUMHDR, I can't work out what the first one means, > >> the second seems to be checking the first byte, which being 0x06 should > be > >> OK, so it is probably the first condition that is failing. > >> > >> Regards > >> > >> Rob > >> > >> > >>> -----Original Message----- > >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >>> edge.com] On Behalf Of Timothe Litt > >>> Sent: 19 May 2013 18:01 > >>> To: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > >>> "KMCIII". > >>> > >>> You need to tell simh what vector to use when you tell it about the > >>> pending interrupt. Most devices have only one vector. The KMC (and > >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > >>> VEC_KDP * kmcnumber +4, depending on which interrupt is being > granted. > >>> (Or whatever symbol you used.) A should be generated by RDI; B by > RDO. > >>> > >>> That will tell simh how to find the right service routine. > >>> > >>> IIRC, if both happen to be pending at the same time, A takes > precedence. > >>> > >>> Without seeing the code, I can't be more explicit... > >>> > >>> Oh, be careful when you talk about bit numbers. The unibus is > >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 12:36, Robert Jarratt wrote: > >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > >>>> not an A, so that would make sense. I have A vectored at bit 8, and > >>>> B at bit > >>> 9. > >>>> Are you referring to this code: > >>>> > >>>> ;HERE FOR INPUT INTERRUPTS > >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > >>>> TRNN T2,KMCRDI ;AND IS IT READY ? > >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the > >>> driver queue, or RDI not set > >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > >>> FLAG << CSR BIT requesting an A interrupt > >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > >>> when driver queue empty > >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > >>>> << the command is then removed from the driver queue and written > to > >>>> the KMC. The KMC > >>> << must clear RDI until it is ready to take the next command. (Note > >>> that otherwise if the queue depth >1, the << A interrupt will happen > >>> immediately. > >>>> If so, then despite the fact that I am setting bit 9 in the > >>>> interrupt request, it seems to be going to the A interrupt handler. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>>> edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 17:01 > >>>>> Cc: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an A > >>>> interrupt. > >>>>> (KMCRDI is 20; RDO is 200) > >>>>> > >>>>> RDYO should always go to IVB; RDYI to IVA. > >>>>> > >>>>> Since we took an IVA interrupt, the driver thinks its trying to > >>>>> give the > >>>> KMC a > >>>>> command, but the interrupt is going to the wrong vector since RDYI > >>>>> is not > >>>> set. > >>>>> So either you're generating an IVA but setting the wrong status > >>>>> bit, or generating an Ivb event but not to the right vector. Or > >>>>> perhaps you have > >>>> an > >>>>> overrun - the interrupt has to be cleared when the drive clears the > >>>>> RDx > >>>> bit. > >>>>> The data looks like a DDCMP start, less the CRCs. That indicates > >>>>> that a > >>>> fair bit > >>>>> of stuff is working; this is the data that the -10 provides to the > > KMC. > >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > >>>>> and > >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >>>>> CRC errors are reported by control out bits. Since the KMC both > >>>>> adds on transmit and removes/checks on receive, and you are > running > >>>>> over an error- checked transport, you can get away with not > >>>>> simulating this - unless you want to interoperate with an interface > >>>>> that does add the > >>> CRCs. > >>>>> Even if the systems are cloned, the DDCMP layer should come up; > >>>>> you'll die later when transport detects a duplicate DECnet node > > number. > >>>>> > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 11:01, Robert Jarratt wrote: > >>>>>> What is curious now is that I have two instances (identical > >>>>>> clones) > >>>> running > >>>>>> attempting to talk to each other. The first message one sends to > >>>>>> the > >>>> other > >>>>>> crashes the OS: > >>>>>> > >>>>>> ********** > >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>>>>> ********** > >>>>>> > >>>>>> The odd thing is that I have delivered the same data that was sent > >>>>>> from > >>>> the > >>>>>> other end, so it should be valid data. > >>>>>> > >>>>>> The data is: 05 06 C0 00 00 01 > >>>>>> > >>>>>> That data does not seem to completely match the DDCMP spec I > have, > >>>>>> I > >>>>> think > >>>>>> some checksum is supposed to follow. Is that supposed to be added > >>>>>> by the > >>>>> KMC > >>>>>> perhaps? > >>>>>> > >>>>>> I don't fully expect it to work because they are clones so would > >>>>>> expect > >>>>> some > >>>>>> kind of error, but would not expect a crash, or am I wrong? > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Robert Jarratt > >>>>>>> Sent: 19 May 2013 15:21 > >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>> I have made some progress. I realised that I did not have the > >>>>>>> interrupt acknowledgement routines set up in the DIB. It is > >>>>>>> working a bit better > >>>>>> now. > >>>>>>> I have indeed seen some commands to read the ram and verify the > >>>>>>> microcode, it does all this to check the KMC is working before > >>>>>>> enabling > >>>>>> it. > >>>>>>> This particular code has never (as far as I know) worked for the > >>>>>>> 11 or > >>>> the > >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > >>>>>>> with now came from someone else and was written for the PDP1) > for > >>>>>>> a > >>> much > >>>>>>> older version of SIMH. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Rob > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: simh-bounces at trailing-edge.com > >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe > >>>>>>>> Litt > >>>>>>>> Sent: 19 May 2013 14:54 > >>>>>>>> To: simh at trailing-edge.com > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>> > >>>>>>>>> I am pretty sure I am doing all the things you mention already > >>>>>>>> Then I need a trace of what's happening to the registers, and > >>>>>>>> what > >>>> simh > >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to > >>>> follow > >>>>>>>> if you output both octal and decode the register names/fields, > >>>>>>>> though I > >>>>>>> can > >>>>>>>> still think - slowly- in octal.) > >>>>>>>> > >>>>>>>> Also, I thought this code was working for the -11/VAX. If so, > >>>>>>>> the basics > >>>>>>> must > >>>>>>>> be OK, though the drivers may well take a different approach to > >>>>>>>> the > >>>>>>> device. > >>>>>>>> Received data should produce either a control-out (error, e.g. > >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out B > >> interrupt. > >>>>>>>> The > >>>>>>> message > >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>>>>> > >>>>>>>> Transmit done - also note that we ignore interrupts unless the > >>>>>>>> 'last > >>>>>>> buffer' bit > >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, and > >>>>>>>> require two interrupts.) > >>>>>>>> > >>>>>>>> Finally, I'm not sure if you'll see it used, but there is code > >>>>>>>> in the > >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > (KMCSUP > >>>>>>>> 400) > >>>>> to > >>>>>>>> force the microcontroller to execute several known instructions > >>>>>>>> - to > >>>>>>> access its > >>>>>>>> data ram, registers & PC. This is primarily used to dump a KMC > >>>>>>>> that halts > >>>>>>> - it > >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. But > >>>>>>>> some of these are also used to verify data ram at initialization. > >>>>>>>> Failure to > >>>>>>> verify will > >>>>>>>> cause the device to be disabled. We can go down that path if > >>>>>>>> you see > >>>>>>> those > >>>>>>>> bits being set in a trace. > >>>>>>>> > >>>>>>>> Look for KMCXCT calls in > >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>>>>> sources/kdpsrv.mac.html > >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined in > >>>>>>>> http://bitsavers.trailing- > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > OP- > >>>>>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>>>>> nual.pdf > >>>>>>>> >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > OP- > >>>>>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>>>>> 0Manual.pdf> > >>>>>>>> The subset is pretty small - load address register, load/store > >>>>>>>> indirect > >>>>>>> (with > >>>>>>>> increment), & branch. I think you ought to be able to crash > >>>>>>>> simh if an unknown instruction is forced, including a branch to > >>>>>>>> an address other than > >>>>>>> 0. > >>>>>>>> Ugly device, ugly driver. Sigh. > >>>>>>>> > >>>>>>>> > >>>>>>>> This communication may not represent my employer's views, if > >>>>>>>> any, on the matters discussed. > >>>>>>>> > >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>>>>> Thanks Timothe, > >>>>>>>>> > >>>>>>>>> I am pretty sure I am doing all the things you mention already > >>>>>>>>> (sorry I didn't make that clear), but I will check through > >>>>>>>>> everything you have said, just in case I have missed something. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Rob > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>> bounces at trailing- > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>>>> Sent: 19 May 2013 11:26 > >>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>> > >>>>>>>>>> A couple of other things come to mind (naturally, after > >>>>>>>>>> pushing > >>>>>>> 'send'): > >>>>>>>>>> Initialization will load/verify the microcode. That has to > > work. > >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in > >>>>>>>>>> and control-in command to establish the DUP CSR address, > >>>>>>>>>> buffers, line > >>>>>>>> mode/enable. > >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating an > >>>>>>>>>> A vector interrupt. > >>>>>>>>>> > >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>>>>> (BSIO) and bit > >>>>>>>>> clear > >>>>>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>>>>> > >>>>>>>>>> For better directed hints, I'd need more detail on what is and > >>>>>>>>>> isn't > >>>>>>>>> happening. > >>>>>>>>>> This communication may not represent my employer's views, if > >>>>>>>>>> any, on the matters discussed. > >>>>>>>>>> > >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>> bounces at trailing- > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > Code? > >>>>>>>>>>>> > >>>>>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me > at > >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > KMC11? > >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to do > >>>>>>>>>>>>> something and read back some values, but I don't know > what > >>>>>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>>>>> Hi, Rob, > >>>>>>>>>>>> > >>>>>>>>>>>> http://pdp-10.trailing- > >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>>>>> l > >>>>>>>>>>>> > >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Rich > >>> _______________________________________________ > >>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>>> I am making some progress with getting the KMC/DUP > >> emulation > >>>>>>>> working > >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > >>>>>>>>>>> which is the interrupts to tell the OS that the KMC has > >>>>>>>>>>> processed a > >>>>>> buffer. > >>>>>>>>>>> The OS sets the interrupt enable bit and when I have > >>>>>>>>>>> something to report to the OS I set the relevant interrupt > >>>>>>>>>>> bit. However, nothing happens when I do that. I am > wondering > >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > > (decimal). > >>>>>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>>>>> > >>>>>>>>>>> Can anyone help? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> > >>>>>>>>>>> Rob > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Simh mailing list > >>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>> _______________________________________________ > >>>>>>> Simh mailing list > >>>>>>> Simh at trailing-edge.com > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 26 04:09:01 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 26 May 2013 09:09:01 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> Message-ID: <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> Tim, I have been looking very closely at how I am writing to the memory and I cannot see anything obviously wrong. Let me run you through one receive buffer transfer with some extracts from the log, see if you can spot any flaws: On startup I get two receive buffers as follows: DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) DBG(285632654)> KMC CMD: Descriptor for rx buffer: DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor address=0x93C8(111710 octal) DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 sel6=020000 DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) DBG(285632752)> KMC CMD: Descriptor for rx buffer: DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor address=0x9558(112530 octal) A little while later I receive the 6 bytes of data from the peer: DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). Descriptor is: DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to address=0x93D8(111730 octal), bytes=6 dma ub write 0x000093d8=003005(oct) dma ub write 0x000093da=000300(oct) dma ub write 0x000093dc=000400(oct) dma ub write 0x000093cc=101400(oct) So the memory appears to get written correctly to the correct location. I then transfer the buffer out to the OS using an output command (no detailed trace for that), this is immediately followed by me receiving a new receive buffer (the very one I just sent, so I think the output transfer must have worked) and the error from the OS: DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) DBG(582051478)> KMC CMD: Descriptor for rx buffer: DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor address=0x93C8(111710 octal) ******************** *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 *BAD DDCMP HEADER *ADDITIONAL DATA: 746314746314, 746314777777 ******************** My suspicion fell on the code to write the data to the memory, this is the unibus_write code: extern t_stat unibus_write(int32 data, int32 addr) { uint16 d; d = data & 0xFFFF; return Map_WriteW (addr, 2, &d); } Which looks OK to me. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Robert Jarratt > Sent: 19 May 2013 22:47 > To: 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Thanks, that sounds likely, I will check how I am writing to memory. > > Regards > > Rob > > > -----Original Message----- > > From: Timothe Litt [mailto:litt at ieee.org] > > Sent: 19 May 2013 21:41 > > To: Robert Jarratt > > Cc: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > This is progress. Looks to me like the data isn't being stored properly. > > > > The ADDITIONAL DATA is the first 8 bytes of the data buffer. The > > SKIPL says the sign bit is set (which it is in 7463...). > > That's not possible. > > > > So I suspect you're not writing the data thru the UBA map correctly. > > > > Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > > words packed into 18-bit 1/2 words. > > This looks like: > > > > /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > > / /-- The ENQ goes here > > / / -- The START goes here > > ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! > > byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > > > > Since 00 is constant, the first digit can't be > 1. 7 mumble is. > > > > Thus for 05 06 (ENQ START), we should see something like 3005,,... in > > the first word. > > (5 + 6 << 8) > > > > Also, you need to map the UBA address to PDP-10 memory (which you > seem > > to be doing for reads). > > > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 16:06, Robert Jarratt wrote: > > > Oops, meant to say the first byte sent is 0x05. > > > > > >> -----Original Message----- > > >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > > >> Sent: 19 May 2013 21:01 > > >> To: 'Timothe Litt'; 'simh at trailing-edge.com' > > >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> Thanks! There was a bug in my interrupt acknowledge routine. With > > >> that fixed the interrupts now seem to be working OK. I have made > > >> progress, > > with > > >> the two clones talking to each other I get this now: > > >> > > >> > > >> ******************** > > >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > > >> *BAD DDCMP HEADER > > >> *ADDITIONAL DATA: 746314746314, 746314777777 > > >> ******************** > > >> > > >> I am going to have to re-learn MACRO to work out why it is failing. > > >> The > > > code I > > >> see has two jumps to BUMHDR, I can't work out what the first one > > >> means, the second seems to be checking the first byte, which being > > >> 0x06 should > > be > > >> OK, so it is probably the first condition that is failing. > > >> > > >> Regards > > >> > > >> Rob > > >> > > >> > > >>> -----Original Message----- > > >>> From: simh-bounces at trailing-edge.com > > >>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > > >>> Sent: 19 May 2013 18:01 > > >>> To: simh at trailing-edge.com > > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>> > > >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > > >>> "KMCIII". > > >>> > > >>> You need to tell simh what vector to use when you tell it about > > >>> the pending interrupt. Most devices have only one vector. The KMC > (and > > >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So > in > > >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber > > >>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being > > granted. > > >>> (Or whatever symbol you used.) A should be generated by RDI; B by > > RDO. > > >>> > > >>> That will tell simh how to find the right service routine. > > >>> > > >>> IIRC, if both happen to be pending at the same time, A takes > > precedence. > > >>> > > >>> Without seeing the code, I can't be more explicit... > > >>> > > >>> Oh, be careful when you talk about bit numbers. The unibus is > > >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > >>> > > >>> This communication may not represent my employer's views, if any, > > >>> on the matters discussed. > > >>> > > >>> On 19-May-13 12:36, Robert Jarratt wrote: > > >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B > > >>>> interrupt, not an A, so that would make sense. I have A vectored > > >>>> at bit 8, and B at bit > > >>> 9. > > >>>> Are you referring to this code: > > >>>> > > >>>> ;HERE FOR INPUT INTERRUPTS > > >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > > >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > > >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > > >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > > >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > >>>> TRNN T2,KMCRDI ;AND IS IT READY ? > > >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the > > >>> driver queue, or RDI not set > > >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > > >>> FLAG << CSR BIT requesting an A interrupt > > >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > > >>> when driver queue empty > > >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > >>>> << the command is then removed from the driver queue and written > > to > > >>>> the KMC. The KMC > > >>> << must clear RDI until it is ready to take the next command. > > >>> (Note that otherwise if the queue depth >1, the << A interrupt > > >>> will happen immediately. > > >>>> If so, then despite the fact that I am setting bit 9 in the > > >>>> interrupt request, it seems to be going to the A interrupt handler. > > >>>> > > >>>> Regards > > >>>> > > >>>> Rob > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>>> edge.com] On Behalf Of Timothe Litt > > >>>>> Sent: 19 May 2013 17:01 > > >>>>> Cc: simh at trailing-edge.com > > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>> > > >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an > > >>>>> A > > >>>> interrupt. > > >>>>> (KMCRDI is 20; RDO is 200) > > >>>>> > > >>>>> RDYO should always go to IVB; RDYI to IVA. > > >>>>> > > >>>>> Since we took an IVA interrupt, the driver thinks its trying to > > >>>>> give the > > >>>> KMC a > > >>>>> command, but the interrupt is going to the wrong vector since > > >>>>> RDYI is not > > >>>> set. > > >>>>> So either you're generating an IVA but setting the wrong status > > >>>>> bit, or generating an Ivb event but not to the right vector. Or > > >>>>> perhaps you have > > >>>> an > > >>>>> overrun - the interrupt has to be cleared when the drive clears > > >>>>> the RDx > > >>>> bit. > > >>>>> The data looks like a DDCMP start, less the CRCs. That > > >>>>> indicates that a > > >>>> fair bit > > >>>>> of stuff is working; this is the data that the -10 provides to > > >>>>> the > > > KMC. > > >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > > >>>>> and > > >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > > >>>>> CRC errors are reported by control out bits. Since the KMC both > > >>>>> adds on transmit and removes/checks on receive, and you are > > running > > >>>>> over an error- checked transport, you can get away with not > > >>>>> simulating this - unless you want to interoperate with an > > >>>>> interface that does add the > > >>> CRCs. > > >>>>> Even if the systems are cloned, the DDCMP layer should come up; > > >>>>> you'll die later when transport detects a duplicate DECnet node > > > number. > > >>>>> > > >>>>> This communication may not represent my employer's views, if > > >>>>> any, on the matters discussed. > > >>>>> > > >>>>> On 19-May-13 11:01, Robert Jarratt wrote: > > >>>>>> What is curious now is that I have two instances (identical > > >>>>>> clones) > > >>>> running > > >>>>>> attempting to talk to each other. The first message one sends > > >>>>>> to the > > >>>> other > > >>>>>> crashes the OS: > > >>>>>> > > >>>>>> ********** > > >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > > >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > > >>>>>> ********** > > >>>>>> > > >>>>>> The odd thing is that I have delivered the same data that was > > >>>>>> sent from > > >>>> the > > >>>>>> other end, so it should be valid data. > > >>>>>> > > >>>>>> The data is: 05 06 C0 00 00 01 > > >>>>>> > > >>>>>> That data does not seem to completely match the DDCMP spec I > > have, > > >>>>>> I > > >>>>> think > > >>>>>> some checksum is supposed to follow. Is that supposed to be > > >>>>>> added by the > > >>>>> KMC > > >>>>>> perhaps? > > >>>>>> > > >>>>>> I don't fully expect it to work because they are clones so > > >>>>>> would expect > > >>>>> some > > >>>>>> kind of error, but would not expect a crash, or am I wrong? > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>> bounces at trailing- > > >>>>>>> edge.com] On Behalf Of Robert Jarratt > > >>>>>>> Sent: 19 May 2013 15:21 > > >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>> > > >>>>>>> I have made some progress. I realised that I did not have the > > >>>>>>> interrupt acknowledgement routines set up in the DIB. It is > > >>>>>>> working a bit better > > >>>>>> now. > > >>>>>>> I have indeed seen some commands to read the ram and verify > > >>>>>>> the microcode, it does all this to check the KMC is working > > >>>>>>> before enabling > > >>>>>> it. > > >>>>>>> This particular code has never (as far as I know) worked for > > >>>>>>> the > > >>>>>>> 11 or > > >>>> the > > >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > > >>>>>>> with now came from someone else and was written for the > PDP1) > > for > > >>>>>>> a > > >>> much > > >>>>>>> older version of SIMH. > > >>>>>>> > > >>>>>>> Regards > > >>>>>>> > > >>>>>>> Rob > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: simh-bounces at trailing-edge.com > > >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of > Timothe > > >>>>>>>> Litt > > >>>>>>>> Sent: 19 May 2013 14:54 > > >>>>>>>> To: simh at trailing-edge.com > > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>> > > >>>>>>>>> I am pretty sure I am doing all the things you mention > > >>>>>>>>> already > > >>>>>>>> Then I need a trace of what's happening to the registers, and > > >>>>>>>> what > > >>>> simh > > >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to > > >>>> follow > > >>>>>>>> if you output both octal and decode the register > > >>>>>>>> names/fields, though I > > >>>>>>> can > > >>>>>>>> still think - slowly- in octal.) > > >>>>>>>> > > >>>>>>>> Also, I thought this code was working for the -11/VAX. If > > >>>>>>>> so, the basics > > >>>>>>> must > > >>>>>>>> be OK, though the drivers may well take a different approach > > >>>>>>>> to the > > >>>>>>> device. > > >>>>>>>> Received data should produce either a control-out (error, e.g. > > >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out > > >>>>>>>> B > > >> interrupt. > > >>>>>>>> The > > >>>>>>> message > > >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > > >>>>>>>> > > >>>>>>>> Transmit done - also note that we ignore interrupts unless > > >>>>>>>> the 'last > > >>>>>>> buffer' bit > > >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, > > >>>>>>>> and require two interrupts.) > > >>>>>>>> > > >>>>>>>> Finally, I'm not sure if you'll see it used, but there is > > >>>>>>>> code in the > > >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > > (KMCSUP > > >>>>>>>> 400) > > >>>>> to > > >>>>>>>> force the microcontroller to execute several known > > >>>>>>>> instructions > > >>>>>>>> - to > > >>>>>>> access its > > >>>>>>>> data ram, registers & PC. This is primarily used to dump a > > >>>>>>>> KMC that halts > > >>>>>>> - it > > >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. > > >>>>>>>> But some of these are also used to verify data ram at > initialization. > > >>>>>>>> Failure to > > >>>>>>> verify will > > >>>>>>>> cause the device to be disabled. We can go down that path if > > >>>>>>>> you see > > >>>>>>> those > > >>>>>>>> bits being set in a trace. > > >>>>>>>> > > >>>>>>>> Look for KMCXCT calls in > > >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > >>>>>>>> sources/kdpsrv.mac.html > > >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined > > >>>>>>>> in > > >>>>>>>> http://bitsavers.trailing- > > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > > OP- > > >>>>>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > >>>>>>>> nual.pdf > > >>>>>>>> > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > > OP- > > >>>>>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > >>>>>>>> 0Manual.pdf> > > >>>>>>>> The subset is pretty small - load address register, > > >>>>>>>> load/store indirect > > >>>>>>> (with > > >>>>>>>> increment), & branch. I think you ought to be able to crash > > >>>>>>>> simh if an unknown instruction is forced, including a branch > > >>>>>>>> to an address other than > > >>>>>>> 0. > > >>>>>>>> Ugly device, ugly driver. Sigh. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This communication may not represent my employer's views, if > > >>>>>>>> any, on the matters discussed. > > >>>>>>>> > > >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > > >>>>>>>>> Thanks Timothe, > > >>>>>>>>> > > >>>>>>>>> I am pretty sure I am doing all the things you mention > > >>>>>>>>> already (sorry I didn't make that clear), but I will check > > >>>>>>>>> through everything you have said, just in case I have missed > something. > > >>>>>>>>> > > >>>>>>>>> Regards > > >>>>>>>>> > > >>>>>>>>> Rob > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>> bounces at trailing- > > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt > > >>>>>>>>>> Sent: 19 May 2013 11:26 > > >>>>>>>>>> To: simh at trailing-edge.com > > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>>>> > > >>>>>>>>>> A couple of other things come to mind (naturally, after > > >>>>>>>>>> pushing > > >>>>>>> 'send'): > > >>>>>>>>>> Initialization will load/verify the microcode. That has to > > > work. > > >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in > > >>>>>>>>>> and control-in command to establish the DUP CSR address, > > >>>>>>>>>> buffers, line > > >>>>>>>> mode/enable. > > >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating > > >>>>>>>>>> an A vector interrupt. > > >>>>>>>>>> > > >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > > >>>>>>>>>> (BSIO) and bit > > >>>>>>>>> clear > > >>>>>>>>>> (BCIO) instructions that also touch the KMC. > > >>>>>>>>>> > > >>>>>>>>>> For better directed hints, I'd need more detail on what is > > >>>>>>>>>> and isn't > > >>>>>>>>> happening. > > >>>>>>>>>> This communication may not represent my employer's views, > > >>>>>>>>>> if any, on the matters discussed. > > >>>>>>>>>> > > >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>>>>> bounces at trailing- > > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > > >>>>>>>>>>>> Sent: 08 May 2013 01:02 > > >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > > Code? > > >>>>>>>>>>>> > > >>>>>>>>>>>>> From: "Robert Jarratt" > > >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point > me > > at > > >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > > KMC11? > > >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to > > >>>>>>>>>>>>> do something and read back some values, but I don't > know > > what > > >>>>>>>>>>>>> values it wants to get and so it reports: > > >>>>>>>>>>>> Hi, Rob, > > >>>>>>>>>>>> > > >>>>>>>>>>>> http://pdp-10.trailing- > > >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > > >>>>>>>>>>>> l > > >>>>>>>>>>>> > > >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Rich > > >>> _______________________________________________ > > >>>>>>>>>>>> Simh mailing list > > >>>>>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>>>>>> I am making some progress with getting the KMC/DUP > > >> emulation > > >>>>>>>> working > > >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one > > >>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC > > >>>>>>>>>>> has processed a > > >>>>>> buffer. > > >>>>>>>>>>> The OS sets the interrupt enable bit and when I have > > >>>>>>>>>>> something to report to the OS I set the relevant interrupt > > >>>>>>>>>>> bit. However, nothing happens when I do that. I am > > wondering > > >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > > > (decimal). > > >>>>>>>>>>> I am not sure how to find out which bit I should be setting. > > >>>>>>>>>>> > > >>>>>>>>>>> Can anyone help? > > >>>>>>>>>>> > > >>>>>>>>>>> Regards > > >>>>>>>>>>> > > >>>>>>>>>>> Rob > > >>>>>>>>>>> > > >>>>>>>>>>> > _______________________________________________ > > >>>>>>>>>>> Simh mailing list > > >>>>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>> _______________________________________________ > > >>>>>>> Simh mailing list > > >>>>>>> Simh at trailing-edge.com > > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From litt at ieee.org Sun May 26 06:25:21 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 26 May 2013 06:25:21 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> Message-ID: <51A1E311.4040109@ieee.org> 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...) 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. TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when the buffer is received. This is a paranoia check to see if the KMC is returning a buffer that it didn't write to. Also, the real UBA wouldn't do a read-modify-write on the first 16-bit write (unless read-reverse was set in the UBA map entry). It would simply write the first word. The odd word is also done as a simple write because the UBA saves the even word's data - that's roughly equivalent to RMW. (See http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM-002_tech_Sep79.pdf around page 5-119 for the gory details, including other transfer modes.) Third: The additional data in the bugchk is the 10-side view of the buffer's first two 36-bit words. This is not the correct data. Note that 3 16-bit words are written, which corresponds to your 6 bytes. But the data is the same (0746314) in each word. The unwritten word is 0777777, which is a good sign that the mapping is correct (though not what a real UBA would do). If we clear the two high bits of the data, we get 0146314, which is 0xCCcc. 0xcc happens to be the low byte of the last DMA UB WRITE's address. Perhaps the address and data arguments to your unibus_write routine are swapped? You might want to look at pdp10_tu.c for a more efficient way of doing large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive unibus mapping only once per page, and writes directly to -10 memory - bypassing the bug in Map_WriteW. It also handles NXM reporting, which hopefully the caller to your interface code is doing... Note, though, that the tu works thru a RH11, which is an 18-bit device and the tape is packing bytes into 36-bit words in odd ways. Don't let that confuse you. Yes, KDPSRV will always return the same buffers; that's expected. It has statically allocated buffers for each line's transmit and receive and copies data in and out. This is partly due to byte re-ordering and partly a matter of simplifying UBA mapping register management. This communication may not represent my employer's views, if any, on the matters discussed. On 26-May-13 04:09, Robert Jarratt wrote: > Tim, > > I have been looking very closely at how I am writing to the memory and I > cannot see anything obviously wrong. Let me run you through one receive > buffer transfer with some extracts from the log, see if you can spot any > flaws: > > On startup I get two receive buffers as follows: > > DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 > DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > DBG(285632654)> KMC CMD: Descriptor for rx buffer: > DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) > DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor > address=0x93C8(111710 octal) > > DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 sel6=020000 > DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) > DBG(285632752)> KMC CMD: Descriptor for rx buffer: > DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) > DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor > address=0x9558(112530 octal) > > A little while later I receive the 6 bytes of data from the peer: > > DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 > DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). Descriptor > is: > DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) > DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) > DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) > DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to address=0x93D8(111730 > octal), bytes=6 > dma ub write 0x000093d8=003005(oct) > dma ub write 0x000093da=000300(oct) > dma ub write 0x000093dc=000400(oct) > dma ub write 0x000093cc=101400(oct) > > So the memory appears to get written correctly to the correct location. I > then transfer the buffer out to the OS using an output command (no detailed > trace for that), this is immediately followed by me receiving a new receive > buffer (the very one I just sent, so I think the output transfer must have > worked) and the error from the OS: > > DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 > DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > DBG(582051478)> KMC CMD: Descriptor for rx buffer: > DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) > DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor > address=0x93C8(111710 octal) > > ******************** > *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 > *BAD DDCMP HEADER > *ADDITIONAL DATA: 746314746314, 746314777777 > ******************** > > My suspicion fell on the code to write the data to the memory, this is the > unibus_write code: > > extern t_stat unibus_write(int32 data, int32 addr) > { > uint16 d; > > d = data & 0xFFFF; > > return Map_WriteW (addr, 2, &d); > } > > Which looks OK to me. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Robert Jarratt >> Sent: 19 May 2013 22:47 >> To: 'Timothe Litt' >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> Thanks, that sounds likely, I will check how I am writing to memory. >> >> Regards >> >> Rob >> >>> -----Original Message----- >>> From: Timothe Litt [mailto:litt at ieee.org] >>> Sent: 19 May 2013 21:41 >>> To: Robert Jarratt >>> Cc: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>> This is progress. Looks to me like the data isn't being stored > properly. >>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The >>> SKIPL says the sign bit is set (which it is in 7463...). >>> That's not possible. >>> >>> So I suspect you're not writing the data thru the UBA map correctly. >>> >>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit >>> words packed into 18-bit 1/2 words. >>> This looks like: >>> >>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE >>> / /-- The ENQ goes here >>> / / -- The START goes here >>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! >>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 >>> >>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. >>> >>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in >>> the first word. >>> (5 + 6 << 8) >>> >>> Also, you need to map the UBA address to PDP-10 memory (which you >> seem >>> to be doing for reads). >>> >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 16:06, Robert Jarratt wrote: >>>> Oops, meant to say the first byte sent is 0x05. >>>> >>>>> -----Original Message----- >>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >>>>> Sent: 19 May 2013 21:01 >>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' >>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> Thanks! There was a bug in my interrupt acknowledge routine. With >>>>> that fixed the interrupts now seem to be working OK. I have made >>>>> progress, >>> with >>>>> the two clones talking to each other I get this now: >>>>> >>>>> >>>>> ******************** >>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >>>>> *BAD DDCMP HEADER >>>>> *ADDITIONAL DATA: 746314746314, 746314777777 >>>>> ******************** >>>>> >>>>> I am going to have to re-learn MACRO to work out why it is failing. >>>>> The >>>> code I >>>>> see has two jumps to BUMHDR, I can't work out what the first one >>>>> means, the second seems to be checking the first byte, which being >>>>> 0x06 should >>> be >>>>> OK, so it is probably the first condition that is failing. >>>>> >>>>> Regards >>>>> >>>>> Rob >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: simh-bounces at trailing-edge.com >>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt >>>>>> Sent: 19 May 2013 18:01 >>>>>> To: simh at trailing-edge.com >>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>> >>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT >>>>>> "KMCIII". >>>>>> >>>>>> You need to tell simh what vector to use when you tell it about >>>>>> the pending interrupt. Most devices have only one vector. The KMC >> (and >>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. > So >> in >>>>>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber >>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being >>> granted. >>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by >>> RDO. >>>>>> That will tell simh how to find the right service routine. >>>>>> >>>>>> IIRC, if both happen to be pending at the same time, A takes >>> precedence. >>>>>> Without seeing the code, I can't be more explicit... >>>>>> >>>>>> Oh, be careful when you talk about bit numbers. The unibus is >>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>>>>> >>>>>> This communication may not represent my employer's views, if any, >>>>>> on the matters discussed. >>>>>> >>>>>> On 19-May-13 12:36, Robert Jarratt wrote: >>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B >>>>>>> interrupt, not an A, so that would make sense. I have A vectored >>>>>>> at bit 8, and B at bit >>>>>> 9. >>>>>>> Are you referring to this code: >>>>>>> >>>>>>> ;HERE FOR INPUT INTERRUPTS >>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? >>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing in > the >>>>>> driver queue, or RDI not set >>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? >>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE >>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT >>>>>> FLAG << CSR BIT requesting an A interrupt >>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears > request >>>>>> when driver queue empty >>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY >>>>>>> << the command is then removed from the driver queue and written >>> to >>>>>>> the KMC. The KMC >>>>>> << must clear RDI until it is ready to take the next command. >>>>>> (Note that otherwise if the queue depth >1, the << A interrupt >>>>>> will happen immediately. >>>>>>> If so, then despite the fact that I am setting bit 9 in the >>>>>>> interrupt request, it seems to be going to the A interrupt handler. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>> Sent: 19 May 2013 17:01 >>>>>>>> Cc: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an >>>>>>>> A >>>>>>> interrupt. >>>>>>>> (KMCRDI is 20; RDO is 200) >>>>>>>> >>>>>>>> RDYO should always go to IVB; RDYI to IVA. >>>>>>>> >>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>>>>> give the >>>>>>> KMC a >>>>>>>> command, but the interrupt is going to the wrong vector since >>>>>>>> RDYI is not >>>>>>> set. >>>>>>>> So either you're generating an IVA but setting the wrong status >>>>>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>>>>> perhaps you have >>>>>>> an >>>>>>>> overrun - the interrupt has to be cleared when the drive clears >>>>>>>> the RDx >>>>>>> bit. >>>>>>>> The data looks like a DDCMP start, less the CRCs. That >>>>>>>> indicates that a >>>>>>> fair bit >>>>>>>> of stuff is working; this is the data that the -10 provides to >>>>>>>> the >>>> KMC. >>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header >>>>>>>> and >>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >>>>>>>> CRC errors are reported by control out bits. Since the KMC both >>>>>>>> adds on transmit and removes/checks on receive, and you are >>> running >>>>>>>> over an error- checked transport, you can get away with not >>>>>>>> simulating this - unless you want to interoperate with an >>>>>>>> interface that does add the >>>>>> CRCs. >>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>>>>> you'll die later when transport detects a duplicate DECnet node >>>> number. >>>>>>>> This communication may not represent my employer's views, if >>>>>>>> any, on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>>>>> What is curious now is that I have two instances (identical >>>>>>>>> clones) >>>>>>> running >>>>>>>>> attempting to talk to each other. The first message one sends >>>>>>>>> to the >>>>>>> other >>>>>>>>> crashes the OS: >>>>>>>>> >>>>>>>>> ********** >>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>>>>> ********** >>>>>>>>> >>>>>>>>> The odd thing is that I have delivered the same data that was >>>>>>>>> sent from >>>>>>> the >>>>>>>>> other end, so it should be valid data. >>>>>>>>> >>>>>>>>> The data is: 05 06 C0 00 00 01 >>>>>>>>> >>>>>>>>> That data does not seem to completely match the DDCMP spec I >>> have, >>>>>>>>> I >>>>>>>> think >>>>>>>>> some checksum is supposed to follow. Is that supposed to be >>>>>>>>> added by the >>>>>>>> KMC >>>>>>>>> perhaps? >>>>>>>>> >>>>>>>>> I don't fully expect it to work because they are clones so >>>>>>>>> would expect >>>>>>>> some >>>>>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>>>>> Sent: 19 May 2013 15:21 >>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> I have made some progress. I realised that I did not have the >>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>>>>> working a bit better >>>>>>>>> now. >>>>>>>>>> I have indeed seen some commands to read the ram and verify >>>>>>>>>> the microcode, it does all this to check the KMC is working >>>>>>>>>> before enabling >>>>>>>>> it. >>>>>>>>>> This particular code has never (as far as I know) worked for >>>>>>>>>> the >>>>>>>>>> 11 or >>>>>>> the >>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>>>>> with now came from someone else and was written for the >> PDP1) >>> for >>>>>>>>>> a >>>>>> much >>>>>>>>>> older version of SIMH. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of >> Timothe >>>>>>>>>>> Litt >>>>>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>> >>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>> already >>>>>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>>>>> what >>>>>>> simh >>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest > to >>>>>>> follow >>>>>>>>>>> if you output both octal and decode the register >>>>>>>>>>> names/fields, though I >>>>>>>>>> can >>>>>>>>>>> still think - slowly- in octal.) >>>>>>>>>>> >>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If >>>>>>>>>>> so, the basics >>>>>>>>>> must >>>>>>>>>>> be OK, though the drivers may well take a different approach >>>>>>>>>>> to the >>>>>>>>>> device. >>>>>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out >>>>>>>>>>> B >>>>> interrupt. >>>>>>>>>>> The >>>>>>>>>> message >>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>>>>> >>>>>>>>>>> Transmit done - also note that we ignore interrupts unless >>>>>>>>>>> the 'last >>>>>>>>>> buffer' bit >>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, >>>>>>>>>>> and require two interrupts.) >>>>>>>>>>> >>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is >>>>>>>>>>> code in the >>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step >>> (KMCSUP >>>>>>>>>>> 400) >>>>>>>> to >>>>>>>>>>> force the microcontroller to execute several known >>>>>>>>>>> instructions >>>>>>>>>>> - to >>>>>>>>>> access its >>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a >>>>>>>>>>> KMC that halts >>>>>>>>>> - it >>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. >>>>>>>>>>> But some of these are also used to verify data ram at >> initialization. >>>>>>>>>>> Failure to >>>>>>>>>> verify will >>>>>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>>>>> you see >>>>>>>>>> those >>>>>>>>>>> bits being set in a trace. >>>>>>>>>>> >>>>>>>>>>> Look for KMCXCT calls in >>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>>>>> sources/kdpsrv.mac.html >>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined >>>>>>>>>>> in >>>>>>>>>>> http://bitsavers.trailing- >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- >>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>>>>> nual.pdf >>>>>>>>>>> >>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- >>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>>>>> 0Manual.pdf> >>>>>>>>>>> The subset is pretty small - load address register, >>>>>>>>>>> load/store indirect >>>>>>>>>> (with >>>>>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>>>>> simh if an unknown instruction is forced, including a branch >>>>>>>>>>> to an address other than >>>>>>>>>> 0. >>>>>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>>> any, on the matters discussed. >>>>>>>>>>> >>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>>>>> Thanks Timothe, >>>>>>>>>>>> >>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>> already (sorry I didn't make that clear), but I will check >>>>>>>>>>>> through everything you have said, just in case I have missed >> something. >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>>> >>>>>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>>>>> pushing >>>>>>>>>> 'send'): >>>>>>>>>>>>> Initialization will load/verify the microcode. That has to >>>> work. >>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base-in >>>>>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>>>>> buffers, line >>>>>>>>>>> mode/enable. >>>>>>>>>>>>> These require that the KMC respond to KMCRQI by initiating >>>>>>>>>>>>> an A vector interrupt. >>>>>>>>>>>>> >>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>>>>> (BSIO) and bit >>>>>>>>>>>> clear >>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>>>>> >>>>>>>>>>>>> For better directed hints, I'd need more detail on what is >>>>>>>>>>>>> and isn't >>>>>>>>>>>> happening. >>>>>>>>>>>>> This communication may not represent my employer's views, >>>>>>>>>>>>> if any, on the matters discussed. >>>>>>>>>>>>> >>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >>> Code? >>>>>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point >> me >>> at >>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the >>> KMC11? >>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to >>>>>>>>>>>>>>>> do something and read back some values, but I don't >> know >>> what >>>>>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rich >>>>>> _______________________________________________ >>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP >>>>> emulation >>>>>>>>>>> working >>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one >>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC >>>>>>>>>>>>>> has processed a >>>>>>>>> buffer. >>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am >>> wondering >>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 >>>> (decimal). >>>>>>>>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can anyone help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>> _______________________________________________ >>>>>>>>>> Simh mailing list >>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From radioengr at gmail.com Sun May 26 12:01:32 2013 From: radioengr at gmail.com (Rob Doyle) Date: Sun, 26 May 2013 09:01:32 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A1E311.4040109@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> Message-ID: <51A231DC.60708@gmail.com> On 5/26/2013 3:25 AM, Timothe Litt wrote: > 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. ...but not unconditionally, right? The KS10 needs to do 18-bit IO for the disk interfaces. The UBA bridge can be configured to do 18-bit IO or 16-bit IO. See DISABLE bit in the UBA paging RAM in the technical spec that you referenced on page 5-105. (I didn't look to see if that was implemented correctly in SIMH) Rob Doyle From litt at ieee.org Sun May 26 12:50:55 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 26 May 2013 12:50:55 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A231DC.60708@gmail.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <51A231DC.60708@gmail.com> Message-ID: <51A23D6F.7020203@ieee.org> > ...but not unconditionally, right? Valid concern, but the devil is in the details. My note was carefully phrased. The disable bit only effects NPR reads; it replaces the two high bits as they are transferred to the Unibus. This is because on a normal (16-bit) unibus, these are PA and PB (byte parity). If they were were transfered, they could cause Unibus parity errors in some 16-bit devices. This is mostly ignored in simh. The tape errors if DISABLE is set, as it knows it's an 18-bit device. (pdp10_ty.c:282) This isn't faithful to the hardware. (The RH has no visibility to the UBA paging RAM, so it would just write zeros to where those bits get swizzled on the tape.) But it would catch an OS programming error. The disable bit can be ignored by 16-bit device emulations since they don't get or check unibus parity. (And if you're tempted to implement some error, note that TOPS-20 doesn't set it for the KDP even though it should.) NPR writes are rather more involved per the spec I cited. Basically, the UBA tries to minimize KS bus transactions by avoiding RPW when possible. It takes advantage of the fact that NPR transfers are to increasing (or with read reverse, decreasing) addresses & caches half words. So writing word 0 (high 1/2 word) will save the data, allowing the next NPR write to merge with the saved data, allowing a KS write cycle (rather than RPW). For read reverse, same idea but backwards. The data comes from the Unibus; 16-bt devices drive or default PA & PB as zero unless they implement parity. Aside from memory, very few do. 18-bit devices are unique to the KS10; IIRC, only the RH11-C uses PA & PB for data. (At one point I considered creating an 18-bit UDA50 variant, but never did.) The disk and tape versions differ slightly in that the disk controller uses bus hog mode. See P 5-94 - 5-100. Note that in figure 5-47, NPR byte writes (which the KMC does) write 0s in the high bits. This is what's not being emulated. NPR word writes could be 16 or 18 bits; the high 2 bits come from the Unibus, but as 16-bit IO devices don't drive them, they default to zero. Simh devices need to treat the high bits as the real devices would. The Map_WriteW routine probably should be taking 18 bit data, with the caller deciding what to put in the high two bits. But that's inconvenient, because C has a 16-bit datatype. So it could use a void * with a mode flag, or have two routines, or... But since the only known 18-bit devices are the RH11s and they don't use this routine, simh could get by with simply clearing the bits. Or as I suggested, the KMC would be better served doing what the RH emulators do & writing memory directly. This would save many redundant UBA page translations when long messages are transferred, as well as avoid this bug. As I pointed out, pdp10_tu.c (and pdp10_rp.c) don't use the routine in question; they directly map unibus addresses to/from PDP-10 memory & write the full 360bt word. (e.g pdp10_tu.c:906 in the loop starting at :896). I was the last maintainer of the DECSYSTEM-2020, and haven't forgotten everything...yet :-) This communication may not represent my employer's views, if any, on the matters discussed. On 26-May-13 12:01, Rob Doyle wrote: > On 5/26/2013 3:25 AM, Timothe Litt wrote: > >> 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. > > ...but not unconditionally, right? > > The KS10 needs to do 18-bit IO for the disk interfaces. The UBA > bridge can be configured to do 18-bit IO or 16-bit IO. > > See DISABLE bit in the UBA paging RAM in the technical spec that you > referenced on page 5-105. > > (I didn't look to see if that was implemented correctly in SIMH) > > Rob Doyle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Mon May 27 05:48:19 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 10:48:19 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A1E311.4040109@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> Message-ID: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> > -----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 > > TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing > the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when > the buffer is received. This is a paranoia check to see if the KMC is > returning a buffer that it didn't write to. > > Also, the real UBA wouldn't do a read-modify-write on the first 16-bit > write (unless read-reverse was set in the UBA map entry). It would > simply write the first word. The odd word is also done as a simple > write because the UBA saves the even word's data - that's roughly > equivalent to RMW. (See > http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM- > 002_tech_Sep79.pdf > around page 5-119 for the gory details, including other transfer modes.) > > Third: The additional data in the bugchk is the 10-side view of the > buffer's first two 36-bit words. This is not the correct data. Note > that 3 16-bit words are written, which corresponds to your 6 bytes. But > the data is the same (0746314) in each word. The unwritten word is > 0777777, which is a good sign that the mapping is correct (though not > what a real UBA would do). If we clear the two high bits of the data, > we get 0146314, which is 0xCCcc. > > 0xcc happens to be the low byte of the last DMA UB WRITE's address. > Perhaps the address and data arguments to your unibus_write routine are > swapped? This bit had me stumped until I really checked what was going on in Map_WriteW. I think there is a bug in it on this line: for ( ; ba < lim; ba++) { /* by bytes */ It should be for ( ; ba < lim; ba += 2) { /* by bytes */ That is why 0xCCCC was getting written to the memory. Now I can see that the right data gets into the OS because I temporarily provoked the bugchk again by not clearing the bits, the additional data looked correct this time. However, I still see one end repeatedly sending the first DDCMP message (05 06 C0 00 00 01), but nothing else happens, no response going the other way, no messages on the console etc. I notice that I do get this message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still don't have the right version of DECnet on this virtual machine? Thanks! Rob > > You might want to look at pdp10_tu.c for a more efficient way of doing > large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive > unibus mapping only once per page, and writes directly to -10 memory - > bypassing the bug in Map_WriteW. It also handles NXM reporting, which > hopefully the caller to your interface code is doing... It looks like rather than patch Map_WriteW above it would be better to write a couple of general DMA routines for transferring large buffers. I will try to do that, let's see if I understand everything you and Rob Doyle have said.... > > Note, though, that the tu works thru a RH11, which is an 18-bit device > and the tape is packing bytes into 36-bit words in odd ways. Don't let > that confuse you. > > Yes, KDPSRV will always return the same buffers; that's expected. It has > statically allocated buffers for each line's transmit and receive and > copies data in and out. This is partly due to byte re-ordering and > partly a matter of simplifying UBA mapping register management. > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 26-May-13 04:09, Robert Jarratt wrote: > > Tim, > > > > I have been looking very closely at how I am writing to the memory and I > > cannot see anything obviously wrong. Let me run you through one receive > > buffer transfer with some extracts from the log, see if you can spot any > > flaws: > > > > On startup I get two receive buffers as follows: > > > > DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 > sel6=020000 > > DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > > DBG(285632654)> KMC CMD: Descriptor for rx buffer: > > DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) > > DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor > > address=0x93C8(111710 octal) > > > > DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 > sel6=020000 > > DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) > > DBG(285632752)> KMC CMD: Descriptor for rx buffer: > > DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) > > DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor > > address=0x9558(112530 octal) > > > > A little while later I receive the 6 bytes of data from the peer: > > > > DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 > > DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). > Descriptor > > is: > > DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) > > DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) > > DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) > > DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to > address=0x93D8(111730 > > octal), bytes=6 > > dma ub write 0x000093d8=003005(oct) > > dma ub write 0x000093da=000300(oct) > > dma ub write 0x000093dc=000400(oct) > > dma ub write 0x000093cc=101400(oct) > > > > So the memory appears to get written correctly to the correct location. I > > then transfer the buffer out to the OS using an output command (no > detailed > > trace for that), this is immediately followed by me receiving a new receive > > buffer (the very one I just sent, so I think the output transfer must have > > worked) and the error from the OS: > > > > DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 > sel6=020000 > > DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > > DBG(582051478)> KMC CMD: Descriptor for rx buffer: > > DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) > > DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor > > address=0x93C8(111710 octal) > > > > ******************** > > *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 > > *BAD DDCMP HEADER > > *ADDITIONAL DATA: 746314746314, 746314777777 > > ******************** > > > > My suspicion fell on the code to write the data to the memory, this is the > > unibus_write code: > > > > extern t_stat unibus_write(int32 data, int32 addr) > > { > > uint16 d; > > > > d = data & 0xFFFF; > > > > return Map_WriteW (addr, 2, &d); > > } > > > > Which looks OK to me. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Robert Jarratt > >> Sent: 19 May 2013 22:47 > >> To: 'Timothe Litt' > >> Cc: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> Thanks, that sounds likely, I will check how I am writing to memory. > >> > >> Regards > >> > >> Rob > >> > >>> -----Original Message----- > >>> From: Timothe Litt [mailto:litt at ieee.org] > >>> Sent: 19 May 2013 21:41 > >>> To: Robert Jarratt > >>> Cc: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>> This is progress. Looks to me like the data isn't being stored > > properly. > >>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The > >>> SKIPL says the sign bit is set (which it is in 7463...). > >>> That's not possible. > >>> > >>> So I suspect you're not writing the data thru the UBA map correctly. > >>> > >>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > >>> words packed into 18-bit 1/2 words. > >>> This looks like: > >>> > >>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > >>> / /-- The ENQ goes here > >>> / / -- The START goes here > >>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! > >>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > >>> > >>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. > >>> > >>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in > >>> the first word. > >>> (5 + 6 << 8) > >>> > >>> Also, you need to map the UBA address to PDP-10 memory (which you > >> seem > >>> to be doing for reads). > >>> > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 16:06, Robert Jarratt wrote: > >>>> Oops, meant to say the first byte sent is 0x05. > >>>> > >>>>> -----Original Message----- > >>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > >>>>> Sent: 19 May 2013 21:01 > >>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' > >>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> Thanks! There was a bug in my interrupt acknowledge routine. With > >>>>> that fixed the interrupts now seem to be working OK. I have made > >>>>> progress, > >>> with > >>>>> the two clones talking to each other I get this now: > >>>>> > >>>>> > >>>>> ******************** > >>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > >>>>> *BAD DDCMP HEADER > >>>>> *ADDITIONAL DATA: 746314746314, 746314777777 > >>>>> ******************** > >>>>> > >>>>> I am going to have to re-learn MACRO to work out why it is failing. > >>>>> The > >>>> code I > >>>>> see has two jumps to BUMHDR, I can't work out what the first one > >>>>> means, the second seems to be checking the first byte, which being > >>>>> 0x06 should > >>> be > >>>>> OK, so it is probably the first condition that is failing. > >>>>> > >>>>> Regards > >>>>> > >>>>> Rob > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: simh-bounces at trailing-edge.com > >>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > >>>>>> Sent: 19 May 2013 18:01 > >>>>>> To: simh at trailing-edge.com > >>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>> > >>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => > BUGHLT > >>>>>> "KMCIII". > >>>>>> > >>>>>> You need to tell simh what vector to use when you tell it about > >>>>>> the pending interrupt. Most devices have only one vector. The KMC > >> (and > >>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. > > So > >> in > >>>>>> the interrupt ack routine, you need to return VEC_KDP * > kmcnumber > >>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being > >>> granted. > >>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by > >>> RDO. > >>>>>> That will tell simh how to find the right service routine. > >>>>>> > >>>>>> IIRC, if both happen to be pending at the same time, A takes > >>> precedence. > >>>>>> Without seeing the code, I can't be more explicit... > >>>>>> > >>>>>> Oh, be careful when you talk about bit numbers. The unibus is > >>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > >>>>>> > >>>>>> This communication may not represent my employer's views, if any, > >>>>>> on the matters discussed. > >>>>>> > >>>>>> On 19-May-13 12:36, Robert Jarratt wrote: > >>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B > >>>>>>> interrupt, not an A, so that would make sense. I have A vectored > >>>>>>> at bit 8, and B at bit > >>>>>> 9. > >>>>>>> Are you referring to this code: > >>>>>>> > >>>>>>> ;HERE FOR INPUT INTERRUPTS > >>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > >>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > >>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > >>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > >>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > >>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > >>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > >>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE > DIFFERENT ? > >>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? > >>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing > in > > the > >>>>>> driver queue, or RDI not set > >>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND > AGAIN ? > >>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF > QUEUE > >>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > >>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > >>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST > INPUT > >>>>>> FLAG << CSR BIT requesting an A interrupt > >>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > >>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears > > request > >>>>>> when driver queue empty > >>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > >>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE > ENTRY > >>>>>>> << the command is then removed from the driver queue and > written > >>> to > >>>>>>> the KMC. The KMC > >>>>>> << must clear RDI until it is ready to take the next command. > >>>>>> (Note that otherwise if the queue depth >1, the << A interrupt > >>>>>> will happen immediately. > >>>>>>> If so, then despite the fact that I am setting bit 9 in the > >>>>>>> interrupt request, it seems to be going to the A interrupt handler. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Rob > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>> Sent: 19 May 2013 17:01 > >>>>>>>> Cc: simh at trailing-edge.com > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>> > >>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an > >>>>>>>> A > >>>>>>> interrupt. > >>>>>>>> (KMCRDI is 20; RDO is 200) > >>>>>>>> > >>>>>>>> RDYO should always go to IVB; RDYI to IVA. > >>>>>>>> > >>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to > >>>>>>>> give the > >>>>>>> KMC a > >>>>>>>> command, but the interrupt is going to the wrong vector since > >>>>>>>> RDYI is not > >>>>>>> set. > >>>>>>>> So either you're generating an IVA but setting the wrong status > >>>>>>>> bit, or generating an Ivb event but not to the right vector. Or > >>>>>>>> perhaps you have > >>>>>>> an > >>>>>>>> overrun - the interrupt has to be cleared when the drive clears > >>>>>>>> the RDx > >>>>>>> bit. > >>>>>>>> The data looks like a DDCMP start, less the CRCs. That > >>>>>>>> indicates that a > >>>>>>> fair bit > >>>>>>>> of stuff is working; this is the data that the -10 provides to > >>>>>>>> the > >>>> KMC. > >>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. > (Header > >>>>>>>> and > >>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >>>>>>>> CRC errors are reported by control out bits. Since the KMC both > >>>>>>>> adds on transmit and removes/checks on receive, and you are > >>> running > >>>>>>>> over an error- checked transport, you can get away with not > >>>>>>>> simulating this - unless you want to interoperate with an > >>>>>>>> interface that does add the > >>>>>> CRCs. > >>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; > >>>>>>>> you'll die later when transport detects a duplicate DECnet node > >>>> number. > >>>>>>>> This communication may not represent my employer's views, if > >>>>>>>> any, on the matters discussed. > >>>>>>>> > >>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: > >>>>>>>>> What is curious now is that I have two instances (identical > >>>>>>>>> clones) > >>>>>>> running > >>>>>>>>> attempting to talk to each other. The first message one sends > >>>>>>>>> to the > >>>>>>> other > >>>>>>>>> crashes the OS: > >>>>>>>>> > >>>>>>>>> ********** > >>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>>>>>>>> ********** > >>>>>>>>> > >>>>>>>>> The odd thing is that I have delivered the same data that was > >>>>>>>>> sent from > >>>>>>> the > >>>>>>>>> other end, so it should be valid data. > >>>>>>>>> > >>>>>>>>> The data is: 05 06 C0 00 00 01 > >>>>>>>>> > >>>>>>>>> That data does not seem to completely match the DDCMP spec I > >>> have, > >>>>>>>>> I > >>>>>>>> think > >>>>>>>>> some checksum is supposed to follow. Is that supposed to be > >>>>>>>>> added by the > >>>>>>>> KMC > >>>>>>>>> perhaps? > >>>>>>>>> > >>>>>>>>> I don't fully expect it to work because they are clones so > >>>>>>>>> would expect > >>>>>>>> some > >>>>>>>>> kind of error, but would not expect a crash, or am I wrong? > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Rob > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>> bounces at trailing- > >>>>>>>>>> edge.com] On Behalf Of Robert Jarratt > >>>>>>>>>> Sent: 19 May 2013 15:21 > >>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>> > >>>>>>>>>> I have made some progress. I realised that I did not have the > >>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is > >>>>>>>>>> working a bit better > >>>>>>>>> now. > >>>>>>>>>> I have indeed seen some commands to read the ram and verify > >>>>>>>>>> the microcode, it does all this to check the KMC is working > >>>>>>>>>> before enabling > >>>>>>>>> it. > >>>>>>>>>> This particular code has never (as far as I know) worked for > >>>>>>>>>> the > >>>>>>>>>> 11 or > >>>>>>> the > >>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > >>>>>>>>>> with now came from someone else and was written for the > >> PDP1) > >>> for > >>>>>>>>>> a > >>>>>> much > >>>>>>>>>> older version of SIMH. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> > >>>>>>>>>> Rob > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: simh-bounces at trailing-edge.com > >>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of > >> Timothe > >>>>>>>>>>> Litt > >>>>>>>>>>> Sent: 19 May 2013 14:54 > >>>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>>> > >>>>>>>>>>>> I am pretty sure I am doing all the things you mention > >>>>>>>>>>>> already > >>>>>>>>>>> Then I need a trace of what's happening to the registers, and > >>>>>>>>>>> what > >>>>>>> simh > >>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest > > to > >>>>>>> follow > >>>>>>>>>>> if you output both octal and decode the register > >>>>>>>>>>> names/fields, though I > >>>>>>>>>> can > >>>>>>>>>>> still think - slowly- in octal.) > >>>>>>>>>>> > >>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If > >>>>>>>>>>> so, the basics > >>>>>>>>>> must > >>>>>>>>>>> be OK, though the drivers may well take a different approach > >>>>>>>>>>> to the > >>>>>>>>>> device. > >>>>>>>>>>> Received data should produce either a control-out (error, e.g. > >>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out > >>>>>>>>>>> B > >>>>> interrupt. > >>>>>>>>>>> The > >>>>>>>>>> message > >>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>>>>>>>> > >>>>>>>>>>> Transmit done - also note that we ignore interrupts unless > >>>>>>>>>>> the 'last > >>>>>>>>>> buffer' bit > >>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, > >>>>>>>>>>> and require two interrupts.) > >>>>>>>>>>> > >>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is > >>>>>>>>>>> code in the > >>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > >>> (KMCSUP > >>>>>>>>>>> 400) > >>>>>>>> to > >>>>>>>>>>> force the microcontroller to execute several known > >>>>>>>>>>> instructions > >>>>>>>>>>> - to > >>>>>>>>>> access its > >>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a > >>>>>>>>>>> KMC that halts > >>>>>>>>>> - it > >>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. > >>>>>>>>>>> But some of these are also used to verify data ram at > >> initialization. > >>>>>>>>>>> Failure to > >>>>>>>>>> verify will > >>>>>>>>>>> cause the device to be disabled. We can go down that path if > >>>>>>>>>>> you see > >>>>>>>>>> those > >>>>>>>>>>> bits being set in a trace. > >>>>>>>>>>> > >>>>>>>>>>> Look for KMCXCT calls in > >>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>>>>>>>> sources/kdpsrv.mac.html > >>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined > >>>>>>>>>>> in > >>>>>>>>>>> http://bitsavers.trailing- > >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- > KMC11- > >>> OP- > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>>>>>>>> nual.pdf > >>>>>>>>>>> >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- > KMC11- > >>> OP- > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>>>>>>>> 0Manual.pdf> > >>>>>>>>>>> The subset is pretty small - load address register, > >>>>>>>>>>> load/store indirect > >>>>>>>>>> (with > >>>>>>>>>>> increment), & branch. I think you ought to be able to crash > >>>>>>>>>>> simh if an unknown instruction is forced, including a branch > >>>>>>>>>>> to an address other than > >>>>>>>>>> 0. > >>>>>>>>>>> Ugly device, ugly driver. Sigh. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This communication may not represent my employer's views, > if > >>>>>>>>>>> any, on the matters discussed. > >>>>>>>>>>> > >>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>>>>>>>> Thanks Timothe, > >>>>>>>>>>>> > >>>>>>>>>>>> I am pretty sure I am doing all the things you mention > >>>>>>>>>>>> already (sorry I didn't make that clear), but I will check > >>>>>>>>>>>> through everything you have said, just in case I have missed > >> something. > >>>>>>>>>>>> Regards > >>>>>>>>>>>> > >>>>>>>>>>>> Rob > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>> bounces at trailing- > >>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>>>>>>> Sent: 19 May 2013 11:26 > >>>>>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > Code? > >>>>>>>>>>>>> > >>>>>>>>>>>>> A couple of other things come to mind (naturally, after > >>>>>>>>>>>>> pushing > >>>>>>>>>> 'send'): > >>>>>>>>>>>>> Initialization will load/verify the microcode. That has to > >>>> work. > >>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base- > in > >>>>>>>>>>>>> and control-in command to establish the DUP CSR address, > >>>>>>>>>>>>> buffers, line > >>>>>>>>>>> mode/enable. > >>>>>>>>>>>>> These require that the KMC respond to KMCRQI by > initiating > >>>>>>>>>>>>> an A vector interrupt. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>>>>>>>> (BSIO) and bit > >>>>>>>>>>>> clear > >>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>>>>>>>> > >>>>>>>>>>>>> For better directed hints, I'd need more detail on what is > >>>>>>>>>>>>> and isn't > >>>>>>>>>>>> happening. > >>>>>>>>>>>>> This communication may not represent my employer's > views, > >>>>>>>>>>>>> if any, on the matters discussed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>>>>> bounces at trailing- > >>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > >>> Code? > >>>>>>>>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point > >> me > >>> at > >>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > >>> KMC11? > >>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to > >>>>>>>>>>>>>>>> do something and read back some values, but I don't > >> know > >>> what > >>>>>>>>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>>>>>>>> Hi, Rob, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://pdp-10.trailing- > >>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>>>>>>>> l > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Rich > >>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP > >>>>> emulation > >>>>>>>>>>> working > >>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one > >>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC > >>>>>>>>>>>>>> has processed a > >>>>>>>>> buffer. > >>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have > >>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt > >>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am > >>> wondering > >>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > >>>> (decimal). > >>>>>>>>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can anyone help? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Rob > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> _______________________________________________ > >>>>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Simh mailing list > >>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >> > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Mon May 27 08:22:57 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 08:22:57 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> Message-ID: <51A35021.40300@ieee.org> Inline. This communication may not represent my employer's views, if any, on the matters discussed. 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... Map_WriteB() isn't clearing the 4 MBZ bits either. M[pa10] = (M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]; should be: M[pa10] = ((M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]) & ~INT64_C(0600000600000)); Looks like Map_WriteW() cloned it. Ideally, Map_WriteW() should take a (16-bit) word count rather than a byte count. That would simplify life for the code and callers alike. But the VAX UBA routines have the same prototype, so I guess we're stuck with it. A more correct fix would be something like the following (but they still should only check the map on page boundaries, which I'm too lazy to code right now). I haven't compiled this, but I think the logic is correct. # Here we optionally allow return of the map entry a10 Map_Addr10 (a10 ba, int32 ub, int32 *ubm) { a10 pa10; int32 vpn = PAG_GETVPN (ba >> 2); /* get PDP-10 page number */ if ((vpn >= UMAP_MEMSIZE) || (ba & XBA_MBZ) || /* invalid map? */ ((ubmap[ub][vpn] & UMAP_VLD) == 0)) return -1; pa10 = (ubmap[ub][vpn] + PAG_GETOFF (ba >> 2)) & PAMASK; if (ubm) *ubm = ubmap[ub][vpn]; /* Return map entry if requested */ return pa10; } /* The next 5 routines would be more efficient if they only called Map_Addr10 for the first transfer & when crossing a page. */ # pass NULL to Map_addr10. No other changes. int32 Map_ReadB (uint32 ba, int32 bc, uint8 *buf) ... pa10 = Map_Addr10 (ba, 1, NULL); ... int32 Map_ReadW (uint32 ba, int32 bc, uint8 *buf) ... pa10 = Map_Addr10 (ba, 1, NULL); ... #replace existing routines - these should correctly handle UB<17:16> /* Byte-mode writes */ int32 Map_WriteB (uint32 ba, int32 bc, uint8 *buf) { uint32 lim; a10 pa10; d10 mask; lim = ba + bc; for ( ; ba < lim; ba++) { /* by bytes */ pa10 = Map_Addr10 (ba, 1, NULL); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } if( (ba&3) == 0 ) { /* byte 0 writes memory; other bytes & <0:1,18:19> of M[] are undefined. */ M[pa10] = ((d10) *buf++) << 18; /* Clears undefined bits */ } else { /* RPW - clear byte position, and UB<17:16> of correct 1/2 word when writing high byte */ mask = 0377<< ubashf[ba & 3]; if (ba & 1) mask |= INT64_C(0000000600000) << ((ba & 2)? 0 : 18); M[pa10] = (M[pa10] & ~mask) | (((d10) *buf++) << ubashf[ba & 3]); } } return 0; } /* Word mode writes; 16-bit data */ int32 Map_WriteW (uint32 ba, int32 bc, uint16 *buf) { uint32 lim; uint32 ubm; a10 pa10; d10 val; ba = ba & ~01; /* align start */ lim = ba + (bc & ~01); for ( ; ba < lim; ba+= 2) { /* by words */ pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } val = *buf++; /* get 16-bit data, clearing <17:16> */ if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18); } else { if (ba & 2) /* Write odd preserves even word */ M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = val << 18; /* Write even clears odd * } return 0; } # new (unused) routine for 18-bit devices. Identical, except input is 18 bits (in 32 bits). /* Word mode writes; 18-bit data */ int32 Map_WriteW18 (uint32 ba, int32 bc, uint32 *buf) { uint32 lim; uint32 ubm; a10 pa10; d10 val; ba = ba & ~01; /* align start */ lim = ba + (bc & ~01); for ( ; ba < lim; ba+= 2) { /* by words */ pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } val = *buf++; /* get 18-bit data */ if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18); } else { /* Write odd preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = val << 18; /* Write even clears odd */ } return 0; } >> TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing >> the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when >> the buffer is received. This is a paranoia check to see if the KMC is >> returning a buffer that it didn't write to. >> >> Also, the real UBA wouldn't do a read-modify-write on the first 16-bit >> write (unless read-reverse was set in the UBA map entry). It would >> simply write the first word. The odd word is also done as a simple >> write because the UBA saves the even word's data - that's roughly >> equivalent to RMW. (See >> http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM- >> 002_tech_Sep79.pdf >> around page 5-119 for the gory details, including other transfer modes.) >> >> Third: The additional data in the bugchk is the 10-side view of the >> buffer's first two 36-bit words. This is not the correct data. Note >> that 3 16-bit words are written, which corresponds to your 6 bytes. But >> the data is the same (0746314) in each word. The unwritten word is >> 0777777, which is a good sign that the mapping is correct (though not >> what a real UBA would do). If we clear the two high bits of the data, >> we get 0146314, which is 0xCCcc. >> >> 0xcc happens to be the low byte of the last DMA UB WRITE's address. >> Perhaps the address and data arguments to your unibus_write routine are >> swapped? > This bit had me stumped until I really checked what was going on in > Map_WriteW. I think there is a bug in it on this line: > > for ( ; ba < lim; ba++) { /* by bytes */ > > It should be > > for ( ; ba < lim; ba += 2) { /* by bytes */ > > That is why 0xCCCC was getting written to the memory. Now I can see that the > right data gets into the OS because I temporarily provoked the bugchk again > by not clearing the bits, the additional data looked correct this time. > > However, I still see one end repeatedly sending the first DDCMP message (05 > 06 C0 00 00 01), but nothing else happens, no response going the other way, > no messages on the console etc. I notice that I do get this message on > bootup though: > > SJ 3: $RUN SYS:NETCON > SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246 > SJ 2: ?UNDEFINED OPERATION CODE > SJ 3: > SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY > > Could it be that I still don't have the right version of DECnet on this > virtual machine? > > Thanks! > > Rob > This I'd need to debug on the -10 side. I suspect it's a JSYS failure. Wild guess: NETCON isn't running with correct privileges? > >> You might want to look at pdp10_tu.c for a more efficient way of doing >> large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive >> unibus mapping only once per page, and writes directly to -10 memory - >> bypassing the bug in Map_WriteW. It also handles NXM reporting, which >> hopefully the caller to your interface code is doing... > > It looks like rather than patch Map_WriteW above it would be better to write > a couple of general DMA routines for transferring large buffers. I will try > to do that, let's see if I understand everything you and Rob Doyle have > said.... Probably can take what I supplied above and simply call Map_Addr10 before the for loops, then update when ba crosses a page boundary. The existing routines should handle large buffers if you do that. > >> Note, though, that the tu works thru a RH11, which is an 18-bit device >> and the tape is packing bytes into 36-bit words in odd ways. Don't let >> that confuse you. >> >> Yes, KDPSRV will always return the same buffers; that's expected. It has >> statically allocated buffers for each line's transmit and receive and >> copies data in and out. This is partly due to byte re-ordering and >> partly a matter of simplifying UBA mapping register management. >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> On 26-May-13 04:09, Robert Jarratt wrote: >>> Tim, >>> >>> I have been looking very closely at how I am writing to the memory and I >>> cannot see anything obviously wrong. Let me run you through one receive >>> buffer transfer with some extracts from the log, see if you can spot any >>> flaws: >>> >>> On startup I get two receive buffers as follows: >>> >>> DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 >> sel6=020000 >>> DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) >>> DBG(285632654)> KMC CMD: Descriptor for rx buffer: >>> DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) >>> DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor >>> address=0x93C8(111710 octal) >>> >>> DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 >> sel6=020000 >>> DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) >>> DBG(285632752)> KMC CMD: Descriptor for rx buffer: >>> DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) >>> DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor >>> address=0x9558(112530 octal) >>> >>> A little while later I receive the 6 bytes of data from the peer: >>> >>> DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 >>> DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). >> Descriptor >>> is: >>> DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) >>> DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) >>> DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) >>> DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to >> address=0x93D8(111730 >>> octal), bytes=6 >>> dma ub write 0x000093d8=003005(oct) >>> dma ub write 0x000093da=000300(oct) >>> dma ub write 0x000093dc=000400(oct) >>> dma ub write 0x000093cc=101400(oct) >>> >>> So the memory appears to get written correctly to the correct location. > I >>> then transfer the buffer out to the OS using an output command (no >> detailed >>> trace for that), this is immediately followed by me receiving a new > receive >>> buffer (the very one I just sent, so I think the output transfer must > have >>> worked) and the error from the OS: >>> >>> DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 >> sel6=020000 >>> DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) >>> DBG(582051478)> KMC CMD: Descriptor for rx buffer: >>> DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) >>> DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor >>> address=0x93C8(111710 octal) >>> >>> ******************** >>> *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 >>> *BAD DDCMP HEADER >>> *ADDITIONAL DATA: 746314746314, 746314777777 >>> ******************** >>> >>> My suspicion fell on the code to write the data to the memory, this is > the >>> unibus_write code: >>> >>> extern t_stat unibus_write(int32 data, int32 addr) >>> { >>> uint16 d; >>> >>> d = data & 0xFFFF; >>> >>> return Map_WriteW (addr, 2, &d); >>> } >>> >>> Which looks OK to me. >>> >>> Regards >>> >>> Rob >>> >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Robert Jarratt >>>> Sent: 19 May 2013 22:47 >>>> To: 'Timothe Litt' >>>> Cc: simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>> Thanks, that sounds likely, I will check how I am writing to memory. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: Timothe Litt [mailto:litt at ieee.org] >>>>> Sent: 19 May 2013 21:41 >>>>> To: Robert Jarratt >>>>> Cc: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> This is progress. Looks to me like the data isn't being stored >>> properly. >>>>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The >>>>> SKIPL says the sign bit is set (which it is in 7463...). >>>>> That's not possible. >>>>> >>>>> So I suspect you're not writing the data thru the UBA map correctly. >>>>> >>>>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit >>>>> words packed into 18-bit 1/2 words. >>>>> This looks like: >>>>> >>>>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE >>>>> / /-- The ENQ goes here >>>>> / / -- The START goes here >>>>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! >>>>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 >>>>> >>>>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. >>>>> >>>>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in >>>>> the first word. >>>>> (5 + 6 << 8) >>>>> >>>>> Also, you need to map the UBA address to PDP-10 memory (which you >>>> seem >>>>> to be doing for reads). >>>>> >>>>> >>>>> This communication may not represent my employer's views, if any, on >>>>> the matters discussed. >>>>> >>>>> On 19-May-13 16:06, Robert Jarratt wrote: >>>>>> Oops, meant to say the first byte sent is 0x05. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >>>>>>> Sent: 19 May 2013 21:01 >>>>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' >>>>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> Thanks! There was a bug in my interrupt acknowledge routine. With >>>>>>> that fixed the interrupts now seem to be working OK. I have made >>>>>>> progress, >>>>> with >>>>>>> the two clones talking to each other I get this now: >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >>>>>>> *BAD DDCMP HEADER >>>>>>> *ADDITIONAL DATA: 746314746314, 746314777777 >>>>>>> ******************** >>>>>>> >>>>>>> I am going to have to re-learn MACRO to work out why it is failing. >>>>>>> The >>>>>> code I >>>>>>> see has two jumps to BUMHDR, I can't work out what the first one >>>>>>> means, the second seems to be checking the first byte, which being >>>>>>> 0x06 should >>>>> be >>>>>>> OK, so it is probably the first condition that is failing. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt >>>>>>>> Sent: 19 May 2013 18:01 >>>>>>>> To: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => >> BUGHLT >>>>>>>> "KMCIII". >>>>>>>> >>>>>>>> You need to tell simh what vector to use when you tell it about >>>>>>>> the pending interrupt. Most devices have only one vector. The KMC >>>> (and >>>>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. >>> So >>>> in >>>>>>>> the interrupt ack routine, you need to return VEC_KDP * >> kmcnumber >>>>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being >>>>> granted. >>>>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by >>>>> RDO. >>>>>>>> That will tell simh how to find the right service routine. >>>>>>>> >>>>>>>> IIRC, if both happen to be pending at the same time, A takes >>>>> precedence. >>>>>>>> Without seeing the code, I can't be more explicit... >>>>>>>> >>>>>>>> Oh, be careful when you talk about bit numbers. The unibus is >>>>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>>>>>>> >>>>>>>> This communication may not represent my employer's views, if any, >>>>>>>> on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 12:36, Robert Jarratt wrote: >>>>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B >>>>>>>>> interrupt, not an A, so that would make sense. I have A vectored >>>>>>>>> at bit 8, and B at bit >>>>>>>> 9. >>>>>>>>> Are you referring to this code: >>>>>>>>> >>>>>>>>> ;HERE FOR INPUT INTERRUPTS >>>>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE >> DIFFERENT ? >>>>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing >> in >>> the >>>>>>>> driver queue, or RDI not set >>>>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND >> AGAIN ? >>>>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF >> QUEUE >>>>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST >> INPUT >>>>>>>> FLAG << CSR BIT requesting an A interrupt >>>>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears >>> request >>>>>>>> when driver queue empty >>>>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE >> ENTRY >>>>>>>>> << the command is then removed from the driver queue and >> written >>>>> to >>>>>>>>> the KMC. The KMC >>>>>>>> << must clear RDI until it is ready to take the next command. >>>>>>>> (Note that otherwise if the queue depth >1, the << A interrupt >>>>>>>> will happen immediately. >>>>>>>>> If so, then despite the fact that I am setting bit 9 in the >>>>>>>>> interrupt request, it seems to be going to the A interrupt > handler. >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>> Sent: 19 May 2013 17:01 >>>>>>>>>> Cc: simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an >>>>>>>>>> A >>>>>>>>> interrupt. >>>>>>>>>> (KMCRDI is 20; RDO is 200) >>>>>>>>>> >>>>>>>>>> RDYO should always go to IVB; RDYI to IVA. >>>>>>>>>> >>>>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>>>>>>> give the >>>>>>>>> KMC a >>>>>>>>>> command, but the interrupt is going to the wrong vector since >>>>>>>>>> RDYI is not >>>>>>>>> set. >>>>>>>>>> So either you're generating an IVA but setting the wrong status >>>>>>>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>>>>>>> perhaps you have >>>>>>>>> an >>>>>>>>>> overrun - the interrupt has to be cleared when the drive clears >>>>>>>>>> the RDx >>>>>>>>> bit. >>>>>>>>>> The data looks like a DDCMP start, less the CRCs. That >>>>>>>>>> indicates that a >>>>>>>>> fair bit >>>>>>>>>> of stuff is working; this is the data that the -10 provides to >>>>>>>>>> the >>>>>> KMC. >>>>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. >> (Header >>>>>>>>>> and >>>>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control > in. >>>>>>>>>> CRC errors are reported by control out bits. Since the KMC both >>>>>>>>>> adds on transmit and removes/checks on receive, and you are >>>>> running >>>>>>>>>> over an error- checked transport, you can get away with not >>>>>>>>>> simulating this - unless you want to interoperate with an >>>>>>>>>> interface that does add the >>>>>>>> CRCs. >>>>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>>>>>>> you'll die later when transport detects a duplicate DECnet node >>>>>> number. >>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>> any, on the matters discussed. >>>>>>>>>> >>>>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>>>>>>> What is curious now is that I have two instances (identical >>>>>>>>>>> clones) >>>>>>>>> running >>>>>>>>>>> attempting to talk to each other. The first message one sends >>>>>>>>>>> to the >>>>>>>>> other >>>>>>>>>>> crashes the OS: >>>>>>>>>>> >>>>>>>>>>> ********** >>>>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>>>>>>> ********** >>>>>>>>>>> >>>>>>>>>>> The odd thing is that I have delivered the same data that was >>>>>>>>>>> sent from >>>>>>>>> the >>>>>>>>>>> other end, so it should be valid data. >>>>>>>>>>> >>>>>>>>>>> The data is: 05 06 C0 00 00 01 >>>>>>>>>>> >>>>>>>>>>> That data does not seem to completely match the DDCMP spec I >>>>> have, >>>>>>>>>>> I >>>>>>>>>> think >>>>>>>>>>> some checksum is supposed to follow. Is that supposed to be >>>>>>>>>>> added by the >>>>>>>>>> KMC >>>>>>>>>>> perhaps? >>>>>>>>>>> >>>>>>>>>>> I don't fully expect it to work because they are clones so >>>>>>>>>>> would expect >>>>>>>>>> some >>>>>>>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>>>>>>> Sent: 19 May 2013 15:21 >>>>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>> >>>>>>>>>>>> I have made some progress. I realised that I did not have the >>>>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>>>>>>> working a bit better >>>>>>>>>>> now. >>>>>>>>>>>> I have indeed seen some commands to read the ram and verify >>>>>>>>>>>> the microcode, it does all this to check the KMC is working >>>>>>>>>>>> before enabling >>>>>>>>>>> it. >>>>>>>>>>>> This particular code has never (as far as I know) worked for >>>>>>>>>>>> the >>>>>>>>>>>> 11 or >>>>>>>>> the >>>>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>>>>>>> with now came from someone else and was written for the >>>> PDP1) >>>>> for >>>>>>>>>>>> a >>>>>>>> much >>>>>>>>>>>> older version of SIMH. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of >>>> Timothe >>>>>>>>>>>>> Litt >>>>>>>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>>> >>>>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>>>> already >>>>>>>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>>>>>>> what >>>>>>>>> simh >>>>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest >>> to >>>>>>>>> follow >>>>>>>>>>>>> if you output both octal and decode the register >>>>>>>>>>>>> names/fields, though I >>>>>>>>>>>> can >>>>>>>>>>>>> still think - slowly- in octal.) >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If >>>>>>>>>>>>> so, the basics >>>>>>>>>>>> must >>>>>>>>>>>>> be OK, though the drivers may well take a different approach >>>>>>>>>>>>> to the >>>>>>>>>>>> device. >>>>>>>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out >>>>>>>>>>>>> B >>>>>>> interrupt. >>>>>>>>>>>>> The >>>>>>>>>>>> message >>>>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>>>>>>> >>>>>>>>>>>>> Transmit done - also note that we ignore interrupts unless >>>>>>>>>>>>> the 'last >>>>>>>>>>>> buffer' bit >>>>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, >>>>>>>>>>>>> and require two interrupts.) >>>>>>>>>>>>> >>>>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is >>>>>>>>>>>>> code in the >>>>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step >>>>> (KMCSUP >>>>>>>>>>>>> 400) >>>>>>>>>> to >>>>>>>>>>>>> force the microcontroller to execute several known >>>>>>>>>>>>> instructions >>>>>>>>>>>>> - to >>>>>>>>>>>> access its >>>>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a >>>>>>>>>>>>> KMC that halts >>>>>>>>>>>> - it >>>>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. >>>>>>>>>>>>> But some of these are also used to verify data ram at >>>> initialization. >>>>>>>>>>>>> Failure to >>>>>>>>>>>> verify will >>>>>>>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>>>>>>> you see >>>>>>>>>>>> those >>>>>>>>>>>>> bits being set in a trace. >>>>>>>>>>>>> >>>>>>>>>>>>> Look for KMCXCT calls in >>>>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>>>>>>> sources/kdpsrv.mac.html >>>>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined >>>>>>>>>>>>> in >>>>>>>>>>>>> http://bitsavers.trailing- >>>>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- >> KMC11- >>>>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>>>>>>> nual.pdf >>>>>>>>>>>>> >>>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- >> KMC11- >>>>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>>>>>>> 0Manual.pdf> >>>>>>>>>>>>> The subset is pretty small - load address register, >>>>>>>>>>>>> load/store indirect >>>>>>>>>>>> (with >>>>>>>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>>>>>>> simh if an unknown instruction is forced, including a branch >>>>>>>>>>>>> to an address other than >>>>>>>>>>>> 0. >>>>>>>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This communication may not represent my employer's views, >> if >>>>>>>>>>>>> any, on the matters discussed. >>>>>>>>>>>>> >>>>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>>>>>>> Thanks Timothe, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>>>> already (sorry I didn't make that clear), but I will check >>>>>>>>>>>>>> through everything you have said, just in case I have missed >>>> something. >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >> Code? >>>>>>>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>>>>>>> pushing >>>>>>>>>>>> 'send'): >>>>>>>>>>>>>>> Initialization will load/verify the microcode. That has to >>>>>> work. >>>>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base- >> in >>>>>>>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>>>>>>> buffers, line >>>>>>>>>>>>> mode/enable. >>>>>>>>>>>>>>> These require that the KMC respond to KMCRQI by >> initiating >>>>>>>>>>>>>>> an A vector interrupt. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>>>>>>> (BSIO) and bit >>>>>>>>>>>>>> clear >>>>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For better directed hints, I'd need more detail on what is >>>>>>>>>>>>>>> and isn't >>>>>>>>>>>>>> happening. >>>>>>>>>>>>>>> This communication may not represent my employer's >> views, >>>>>>>>>>>>>>> if any, on the matters discussed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >>>>> Code? >>>>>>>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point >>>> me >>>>> at >>>>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the >>>>> KMC11? >>>>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to >>>>>>>>>>>>>>>>>> do something and read back some values, but I don't >>>> know >>>>> what >>>>>>>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Rich >>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP >>>>>>> emulation >>>>>>>>>>>>> working >>>>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one >>>>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC >>>>>>>>>>>>>>>> has processed a >>>>>>>>>>> buffer. >>>>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am >>>>> wondering >>>>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 >>>>>> (decimal). >>>>>>>>>>>>>>>> I am not sure how to find out which bit I should be > setting. >>>>>>>>>>>>>>>> Can anyone help? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rob >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Simh mailing list >>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 08:37:25 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 05:37:25 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A35021.40300@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> 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 From litt at ieee.org Mon May 27 08:49:34 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 08:49:34 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> Message-ID: <51A3565E.1050108@ieee.org> 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: From litt at ieee.org Mon May 27 09:18:06 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:18:06 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> Message-ID: <51A35D0E.8050501@ieee.org> This wouldn't be a -10 coding issue. It worked on the real systems. The CR's data transfer in simh may be broken due to the bugs discussed. But the 'unavailable' status is probably that GALAXY has control of the device and expects to spool data via CDRIVE/SPRINT, which may need to be started. See the operator's and galaxy batch documentation. (e.g. http://www.textfiles.com/bitsavers/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol02/AA_H374B_batch.pdf http://www.textfiles.com/bitsavers/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol17/AA-H599C-TB_OperCmdLang.pdf) One of these days I'll might build a monitor with CDR support and try it. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 08:58, Jordi Guillaumes i Pons wrote: > Just Fyi the CD11 does NOT work in TOPS-10. The OS "sees" the device (it shows in RES) but it is always reported as "unavailable". I have plans to teach myself MACRO-10 and have a look at the driver and the simh code like I did with the CR for the '11 and the VAX, but I can't commit myself on a date to do it (I am having too much fun with DECNET-OSI at this moment). > > Jordi Guillaumes i Pons > Barcelona - Catalunya - Europa > > El 27/05/2013, a les 14:49, Timothe Litt va escriure: >> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 09:19:00 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:19:00 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> Message-ID: <51A35D44.5090601@ieee.org> 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: From robert.jarratt at ntlworld.com Mon May 27 09:32:09 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 14:32:09 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A3565E.1050108@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> Message-ID: <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> I also see a reference in pdp11_hk which is the RK611/RK06/RK07 disk controller Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 27 May 2013 13:50 > To: Mark Pizzolato - Info Comm > Cc: Robert Jarratt; simh at trailing-edge.com > 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: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 > > > From litt at ieee.org Mon May 27 09:34:33 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:34:33 -0400 Subject: [Simh] Netcon In-Reply-To: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> Message-ID: <51A360E9.3050107@ieee.org> > owever, I still see one end repeatedly sending the first DDCMP message > (05 06 C0 00 00 01), but nothing else happens, no response going the > other way, no messages on the console etc. I notice that I do get this > message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL > INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % > NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still > don't have the right version of DECnet on this virtual machine? > Thanks! Rob Er, are you still running cloned systems? Make sure the node number and name are different between the two. As I wrote, I'd need to debug this, but it's possible that NETCON just isn't graceful about this. This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 09:35:33 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:35:33 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> Message-ID: <51A36125.3030804@ieee.org> 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:litt at ieee.org] >> Sent: 27 May 2013 13:50 >> To: Mark Pizzolato - Info Comm >> Cc: Robert Jarratt; simh at trailing-edge.com >> 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: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: From litt at ieee.org Mon May 27 10:14:16 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 10:14:16 -0400 Subject: [Simh] Speaking of cards Message-ID: <51A36A38.3060106@ieee.org> Since the CD20 was mentioned, I wondered if there was an 029 emulator available to produce card decks. Haven't found one, but did find http://x3270.bgp.nu/x026.html, which I haven't done much with. It does build on linux and seems to run. It claims to support the 029 character set as well. But it doesn't support drum cards, skip, dup, zero-fill, or anything other than straight typing. Does anyone know of a better emulator? Or know X well enough to feel like adding at least drum card eumlation? https://en.wikipedia.org/wiki/Keypunch documents the drum (or Program) card. I have some blank punch cards, I should scan one as it only comes with some customized images. Does anyone know how to (on windows or Linux) convert a scanned image in a modern format (bmp,jpeg,tiff, etc) to xpm? http://homepage.cs.uiowa.edu/~jones/cards/codes.html has a fair bit of documentation on card formats, including what simh uses. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From aek at bitsavers.org Mon May 27 10:36:19 2013 From: aek at bitsavers.org (Al Kossow) Date: Mon, 27 May 2013 07:36:19 -0700 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: <51A36F63.9050609@bitsavers.org> On 5/27/13 7:14 AM, Timothe Litt wrote: > I have some blank punch cards, I should scan one as it only comes with some customized images. > I can make a high resolution scan of a buff 5081 if it's needed. From tfmorris at gmail.com Mon May 27 10:43:36 2013 From: tfmorris at gmail.com (Tom Morris) Date: Mon, 27 May 2013 10:43:36 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: On Mon, May 27, 2013 at 10:14 AM, Timothe Litt wrote: > > Does anyone know how to (on windows or Linux) convert a scanned image in a > modern format (bmp,jpeg,tiff, etc) to xpm? > ImageMagick supports most formats, including xpm. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfmorris at gmail.com Mon May 27 10:58:34 2013 From: tfmorris at gmail.com (Tom Morris) Date: Mon, 27 May 2013 10:58:34 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: p.s. Love this quote from the card format documentation page On Mon, May 27, 2013 at 10:14 AM, Timothe Litt wrote: > > http://homepage.cs.uiowa.edu/~**jones/cards/codes.html< > http://homepage.cs.uiowa.edu/**%7Ejones/cards/codes.html> > has a fair bit of documentation on card formats, including what simh uses. "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN character set to ASCII. Unfortunately, it appears to have nothing in common with other extensions of the same character set. Given the frequency of typos in DEC's handbooks, it is possible that the problem is with the handbook from which this material was derived." -------------- next part -------------- An HTML attachment was scrubbed... URL: From litt at ieee.org Mon May 27 11:01:22 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 11:01:22 -0400 Subject: [Simh] Speaking of cards In-Reply-To: References: <51A36A38.3060106@ieee.org> Message-ID: <51A37542.60201@ieee.org> > ImageMagick supports most formats, including xpm. > That's way too simple. I even have ImageMagick :-( > I can make a high resolution scan of a buff 5081 if it's needed. I have pink cards for sure...buff wouldn't hurt. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 10:43, Tom Morris wrote: > On Mon, May 27, 2013 at 10:14 AM, Timothe Litt > wrote: > > > Does anyone know how to (on windows or Linux) convert a scanned > image in a modern format (bmp,jpeg,tiff, etc) to xpm? > > > ImageMagick supports most formats, including xpm. > > Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 11:24:43 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 11:24:43 -0400 Subject: [Simh] Speaking of cards In-Reply-To: References: <51A36A38.3060106@ieee.org> Message-ID: <51A37ABB.7000001@ieee.org> Well, TOPS-10 uses this, and our customers were happy. Of course, 029 was much more common in the PDP-10 era. ;THE CHARACTER TRANSLATION TABLES: $HIGH CRCVPT::XWD 350700+T2,CRCVTB XWD 260700+T2,CRCVTB XWD 170700+T2,CRCVTB XWD 100700+T2,CRCVTB ;CODE CONVERSION FOR THE 029 KEYPUNCH ;THE FOLLOWING EQUIVALENCES ARE ARTIFICIALLY DEFINED ;029 KEYTOP ;ASCII 35 ;ASCII 37 ;CENT [ [ ;0-8-2 ] ] ;VERT BAR ^ HAT = L.C. VERT BAR ;UNDERBAR _ UNDERBAR ;NEGATION \ TILDE = L.C. NEGATION ;CHARACTERS ;ZONE/DIGITS CRCVTB: ASCII / 123/ ;N/N-3 ASCII .0/ST. ;0/N-3 ASCII /-JKL/ ;11/N-3 ASCII /HI[./ ;12,8/N-3 ASCII /&ABC/ ;12/N-3 ASCII /QR]$/ ;11,8/N-3 ASCII /YZ\,/ ;0,8/N-3 ASCII /89:#/ ;8/N-3 ASCII /4567/ ;N/4-7 ASCII /UVWX/ ;0/4-7 ASCII /MNOP/ ;11/4-7 ASCII /<(+!/ ;12,8/4-7 ASCII /DEFG/ ;12/4-7 ASCII /*);^/ ;11,8/4-7 ASCII /%_>?/ ;0,8/4-7 ASCII /@'="/ ;8/4-7 ;CODE FOR THE 026 KEYPUNCH A LA H HYMAN ASCII / 123/ ;N/N-3 ASCII .0/ST. ;0/N-3 ASCII /-JKL/ ;11/N-3 ASCII /HI?./ ;12,8/N-3 ASCII /+ABC/ ;12/N-3 ASCII /QR:$/ ;11,8/N-3 ASCII /YZ;,/ ;0,8/N-3 ASCII /89_=/ ;8/N-3 ASCII /4567/ ;N/4-7 ASCII /UVWX/ ;0/4-7 ASCII /MNOP/ ;11/4-7 ASCII /)]&/ ;11,8/4-7 ASCII /("#%/ ;0,8/4-7 ASCII /@^'\/ ;8/4-7 ;HERE IF DATA IS IN ASCII OR BINARY MODE NOTIMG: ILDB U,T3 ;GET COLUMN 1 MOVE T1,U ;SAVE HERE TRZ U,770000 ;JUST COLUMN DATA CAIE U,CODEOF+NEWEOF ;IS IT AN EOF CARD? CAIN U,CODEOF ;OR THIS TYPE? PJRST EOFCRD ;YES--SET FLAGS CAIN U,NEWEOF ;IS IT NEW TYPE EOF? PJRST EOFCRD ;YES--SET FLAGS TRNE S,14 ;BINARY MODE? PJRST CDRBIN ;YES--GO PROCESS IT ;HERE TO PROCESS AN ASCII CARD CAIN U,COD026 ;026 CARD? PJRST SET026 ;YES--SET MODE CAIN U,COD029 ;029 CARD? PJRST SET029 ;YES--SET MODE SKIPA U,T1 ;RESTORE COLUMN 1 AND SKIP NEXT ASCLOP: ILDB U,T3 ;GET NEXT COLUMN TRNE U,100000 ;MULTI-PUNCHED COLUMN? JRST [MOVEI U,"\" ;YES--GET INVALID CHARACTER JRST ASCLO1] ; AND STORE THAT SETZB T1,T2 CAIN U,5000 ;CONVERT "[" MOVEI U,24202 ; TO INTERNAL FORM CAIN U,3000 ;CONVERT "]" MOVEI U,22202 ; TO INTERNAL FORM LDB T2,[POINT 3,U,26] ;GET ZONES PLUS LOW ENCODED BIT TRNE U,3 ;AN 8 OR 9 PUNCH? TRC T2,7 ;YES--ENCODE THAT TRZE U,40000 ;COPY THIS BIT TRO T2,10 ; TO HERE TRNE U,1 ;THIS BIT ON TRO U,10000 ; MEANS THIS BIT SHOULD BE ON LSH U,-^D12 ;POSITION REMAINING CODE BITS TLNE S,CR026 ;026 MODE? TRO T2,20 ;YES--BUMP T2 TO 026 TABLE LDB U,CRCVPT##(U) ;PICK UP ASCII CHAR FROM TABLE ASCLO1: IDPB U,DEVPTR(F) ;PUT INTO USER BUFFER SOJG T4,ASCLOP ;LOOP THRU CARD MOVEI T1,15 ;INSERT IDPB T1,DEVPTR(F) MOVEI T1,12 ;INSERT IDPB T1,DEVPTR(F) PJRST CDRDON ;FINISH UP This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 10:58, Tom Morris wrote: > p.s. Love this quote from the card format documentation page > > > On Mon, May 27, 2013 at 10:14 AM, Timothe Litt > wrote: > > > http://homepage.cs.uiowa.edu/~jones/cards/codes.html > > has a > fair bit of documentation on card formats, including what simh uses. > > > > "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN > character set to ASCII. Unfortunately, it appears to have nothing in > common with other extensions of the same character set. Given the > frequency of typos in DEC's handbooks, it is possible that the problem > is with the handbook from which this material was derived." -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Mon May 27 11:36:00 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 16:36:00 +0100 Subject: [Simh] Netcon In-Reply-To: <51A360E9.3050107@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> Message-ID: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> The disks are cloned but I modified 4-1-config.cmd to change the node name and number. That is all I did. So in one I have the line NODE TOPS20 25 And in the other I have NODE TOPS21 26 I don't know much about how NETCON would get its permissions, it is being started from SYSJOB.RUN, this is what I have in that file after following the instructions in the manual I was following: RUN SYS:ORION RUN SYS:QUASAR RUN SYS:MOUNTR RUN SYS:INFO RUN SYS:MAILER RUN SYS:MAPPER RUN SYS:LPTSPL RUN SYS:LPTSPL RUN SYS:CDRIVE RUN SYS:SPRINT JOB 0 /LOG OPERATOR XX OPERATOR ENA ^ESET LOGIN PSEUDO ^ESET LOGIN CONSOLE ^ESET OPERATOR PTYCON GET SYSTEM:PTYCON.ATO / JOB 1 /LOG OPERATOR XX OPERATOR ENA RUN SYS:BATCON / JOB 2 /LOG OPERATOR XX OPERATOR ENA RUN SYS:FAL / JOB 3 /LOG OPERATOR XX OPERATOR ENA RUN SYS:NETCON / Note that the manual used "\LOG" rather than "/LOG" but was contradictory on this as in some places it was one and in others it was the other. I tried a loopback test, which failed as per the attached log file. One more data point. When I use UETP to verify the configuration I get these errors in the log: $TYPE EXCEPT.LOG.2 ERROR VF2020 27-May-2013 10:32:24 0:00:00 0:00:00 ? Mismatch occurred during verification: Currently installed file: PS:DECNET.BWR.1 644032 P Correct file: PS:DECNET.BWR.1 556602 P ERROR VF2020 27-May-2013 10:32:24 0:00:00 0:00:00 ? Mismatch occurred during verification: Currently installed file: PS:DECNET.DOC.1 350434 P Correct file: PS:DECNET.DOC.1 614303 P They suggest that the docs are not right, but nothing else. Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 27 May 2013 14:35 > To: Robert Jarratt > Cc: simh at trailing-edge.com > Subject: Re: [Simh] Netcon > > > owever, I still see one end repeatedly sending the first DDCMP message > > (05 06 C0 00 00 01), but nothing else happens, no response going the > > other way, no messages on the console etc. I notice that I do get this > > message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL > > INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % > > NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still > > don't have the right version of DECnet on this virtual machine? > > Thanks! Rob > > Er, are you still running cloned systems? Make sure the node number and > name are different between the two. > > As I wrote, I'd need to debug this, but it's possible that NETCON just > isn't graceful about this. > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dnv2ll.log Type: application/octet-stream Size: 6944 bytes Desc: not available URL: From jg at jordi.guillaumes.name Mon May 27 11:39:20 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 17:39:20 +0200 Subject: [Simh] Fwd: Re: Speaking of cards In-Reply-To: <51A37DC1.4070107@jordi.guillaumes.name> References: <51A37DC1.4070107@jordi.guillaumes.name> Message-ID: <51A37E28.4050408@jordi.guillaumes.name> Brrr... Thunderbird keeps replying to the sender instead of to the list by default... -------- Missatge original -------- Assumpte: Re: [Simh] Speaking of cards Data: Mon, 27 May 2013 17:37:37 +0200 De: Jordi Guillaumes i Pons A: Tom Morris Al 27/05/13 16:58, En/na Tom Morris ha escrit: > "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN > character set to ASCII. Unfortunately, it appears to have nothing in > common with other extensions of the same character set. Given the > frequency of typos in DEC's handbooks, it is possible that the problem > is with the handbook from which this material was derived." I recently added a new table (026DEC) to simh which corresponds with what does RSX11 and VMS expect when the reader is in 026 mode. The 029 mode was already correct, with a pair of mistakes I corrected. If you catch any error please open an issue at github so it can be corrected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jg at jordi.guillaumes.name Mon May 27 11:46:53 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 17:46:53 +0200 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A37443.8070002@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> Message-ID: <51A37FED.4010702@jordi.guillaumes.name> Al 27/05/13 16:57, En/na Timothe Litt ha escrit: > CDRIVE is trying to OPEN [sixbit/CDR000/] and fails, but doesn't > bother to say why. > > Too bad that it doesn't use FILOP. instead. > > Anyhow, OPEN will fail if the device doesn't exist, is in use, or > restricted. > > It clearly exists. CDRIVE runs under [1,2], so restricted shouldn't > be a problem. (opr> unrestrict cdr0 shouldn't be necessary, but might > tell us something). systat b should tell us if it's in use by some > other job. .r opr OPR>unrestrict cdr0 OPR> 17:41:59 --Device CDR0: unrestricted-- OPR>start reader 0 OPR> 17:42:10 Reader 0 -- Already Started -- OPR>shutdown reader 0 OPR> 17:42:17 Reader 0 -- Shutdown -- OPR>start reader 0 OPR> 17:42:23 Reader 0 -- Startup Scheduled -- OPR> 17:42:24 Reader 0 -- Not available right now -- OPR> 17:42:28 -- CDRIVE logging out -- All streams have been shutdown OPR>^Z .systat b No busy devices > How is it configured in simh - should be at 3,,777160, vector 230? bitxt1>> show cr CR address=3777160-3777167, vector=230, 1000 cards per minute translation=029 not attached, CD11, auto EOF unknown format > From Mark at infocomm.com Mon May 27 11:48:55 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 08:48:55 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A35D44.5090601@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> 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: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 > > > From litt at ieee.org Mon May 27 12:02:12 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:02:12 -0400 Subject: [Simh] Netcon In-Reply-To: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> Message-ID: <51A38384.2060504@ieee.org> Don't worry about the \ / inconsistency. It's just a delimiter - it needs to match for a given command. LOG OPERATOR + ENA (enable) is what gives permissions. That should be OK. Does spear report any errors from DECnet? Have your tried to use NCP to enable console logging? That should produce the DECnet events. I'd want to login, run NETCON manually with DDT to see what it's complaining about. But first, the other symptom. Only one end sending; no response to START. That's wierd, and nothing will work until it's fixed. If the line is on for both systems, they *both* should be sending STARTs, until one (or both) sends a STACK. Then the other sends ACK, and the link is up. So back to your code. On the end that's not sending anything: are the line and circuit ON? Are you seeing buffers queued? Is the data arriving and being delivered? What's different in its .INI file? How are you specifying the TCP (or UDP) socket destinations/port numbers? Are both ends opening successfully? A trace would help. Or maybe I should try running your code... This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:36, Robert Jarratt wrote: > The disks are cloned but I modified 4-1-config.cmd to change the node name > and number. That is all I did. So in one I have the line > NODE TOPS20 25 > And in the other I have > NODE TOPS21 26 > > I don't know much about how NETCON would get its permissions, it is being > started from SYSJOB.RUN, this is what I have in that file after following > the instructions in the manual I was following: > > RUN SYS:ORION > RUN SYS:QUASAR > RUN SYS:MOUNTR > RUN SYS:INFO > RUN SYS:MAILER > RUN SYS:MAPPER > RUN SYS:LPTSPL > RUN SYS:LPTSPL > RUN SYS:CDRIVE > RUN SYS:SPRINT > JOB 0 /LOG OPERATOR XX OPERATOR > ENA > ^ESET LOGIN PSEUDO > ^ESET LOGIN CONSOLE > ^ESET OPERATOR > PTYCON > GET SYSTEM:PTYCON.ATO > / > JOB 1 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:BATCON > / > JOB 2 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:FAL > / > JOB 3 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:NETCON > / > > Note that the manual used "\LOG" rather than "/LOG" but was contradictory on > this as in some places it was one and in others it was the other. > > I tried a loopback test, which failed as per the attached log file. > > One more data point. When I use UETP to verify the configuration I get these > errors in the log: > > $TYPE EXCEPT.LOG.2 > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.BWR.1 644032 P > Correct file: PS:DECNET.BWR.1 556602 P > > > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.DOC.1 350434 P > Correct file: PS:DECNET.DOC.1 614303 P > > They suggest that the docs are not right, but nothing else. > > Regards > > Rob > >> -----Original Message----- >> From: Timothe Litt [mailto:litt at ieee.org] >> Sent: 27 May 2013 14:35 >> To: Robert Jarratt >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] Netcon >> >>> owever, I still see one end repeatedly sending the first DDCMP message >>> (05 06 C0 00 00 01), but nothing else happens, no response going the >>> other way, no messages on the console etc. I notice that I do get this >>> message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL >>> INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % >>> NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still >>> don't have the right version of DECnet on this virtual machine? >>> Thanks! Rob >> Er, are you still running cloned systems? Make sure the node number and >> name are different between the two. >> >> As I wrote, I'd need to debug this, but it's possible that NETCON just >> isn't graceful about this. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:04:32 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:04:32 -0400 Subject: [Simh] Netcon In-Reply-To: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> Message-ID: <51A38410.8070908@ieee.org> Oh, the loopback - CHKLBP.MAC isn't compiling. I can't tell if the log is jumbled, or if the code is really missing CRLFs. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:36, Robert Jarratt wrote: > The disks are cloned but I modified 4-1-config.cmd to change the node name > and number. That is all I did. So in one I have the line > NODE TOPS20 25 > And in the other I have > NODE TOPS21 26 > > I don't know much about how NETCON would get its permissions, it is being > started from SYSJOB.RUN, this is what I have in that file after following > the instructions in the manual I was following: > > RUN SYS:ORION > RUN SYS:QUASAR > RUN SYS:MOUNTR > RUN SYS:INFO > RUN SYS:MAILER > RUN SYS:MAPPER > RUN SYS:LPTSPL > RUN SYS:LPTSPL > RUN SYS:CDRIVE > RUN SYS:SPRINT > JOB 0 /LOG OPERATOR XX OPERATOR > ENA > ^ESET LOGIN PSEUDO > ^ESET LOGIN CONSOLE > ^ESET OPERATOR > PTYCON > GET SYSTEM:PTYCON.ATO > / > JOB 1 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:BATCON > / > JOB 2 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:FAL > / > JOB 3 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:NETCON > / > > Note that the manual used "\LOG" rather than "/LOG" but was contradictory on > this as in some places it was one and in others it was the other. > > I tried a loopback test, which failed as per the attached log file. > > One more data point. When I use UETP to verify the configuration I get these > errors in the log: > > $TYPE EXCEPT.LOG.2 > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.BWR.1 644032 P > Correct file: PS:DECNET.BWR.1 556602 P > > > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.DOC.1 350434 P > Correct file: PS:DECNET.DOC.1 614303 P > > They suggest that the docs are not right, but nothing else. > > Regards > > Rob > >> -----Original Message----- >> From: Timothe Litt [mailto:litt at ieee.org] >> Sent: 27 May 2013 14:35 >> To: Robert Jarratt >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] Netcon >> >>> owever, I still see one end repeatedly sending the first DDCMP message >>> (05 06 C0 00 00 01), but nothing else happens, no response going the >>> other way, no messages on the console etc. I notice that I do get this >>> message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL >>> INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % >>> NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still >>> don't have the right version of DECnet on this virtual machine? >>> Thanks! Rob >> Er, are you still running cloned systems? Make sure the node number and >> name are different between the two. >> >> As I wrote, I'd need to debug this, but it's possible that NETCON just >> isn't graceful about this. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:09:36 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:09:36 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A37FED.4010702@jordi.guillaumes.name> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> Message-ID: <51A38540.9050903@ieee.org> simh says 'not attached' You need to attach it at the simh prompt to a file of card images. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:46, Jordi Guillaumes i Pons wrote: > Al 27/05/13 16:57, En/na Timothe Litt ha escrit: >> CDRIVE is trying to OPEN [sixbit/CDR000/] and fails, but doesn't >> bother to say why. >> >> Too bad that it doesn't use FILOP. instead. >> >> Anyhow, OPEN will fail if the device doesn't exist, is in use, or >> restricted. >> >> It clearly exists. CDRIVE runs under [1,2], so restricted shouldn't >> be a problem. (opr> unrestrict cdr0 shouldn't be necessary, but >> might tell us something). systat b should tell us if it's in use by >> some other job. > > > .r opr > > OPR>unrestrict cdr0 > OPR> > 17:41:59 --Device CDR0: unrestricted-- > OPR>start reader 0 > OPR> > 17:42:10 Reader 0 -- Already Started -- > OPR>shutdown reader 0 > OPR> > 17:42:17 Reader 0 -- Shutdown -- > OPR>start reader 0 > OPR> > 17:42:23 Reader 0 -- Startup Scheduled -- > OPR> > 17:42:24 Reader 0 -- Not available right now -- > OPR> > 17:42:28 -- CDRIVE logging out -- > All streams have been shutdown > OPR>^Z > .systat b > > No busy devices > >> How is it configured in simh - should be at 3,,777160, vector 230? > bitxt1>> show cr > CR address=3777160-3777167, vector=230, 1000 cards per minute > translation=029 > not attached, CD11, auto EOF > unknown format > > >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:27:43 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:27:43 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> Message-ID: <51A3897F.7020203@ieee.org> Hopefully, when the KDP is working Rob will merge (and if necessary debug) my changes & commit them to fix both problems. Ideally adding the page optimization, but beggars can't be choosers. If he doesn't I'll try to get to that later (if I have commit access to simh on github). I suppose I should see about building a current version, as I seem to be in the middle of debugging several things by Braille... (Or is this simply a memory test for me :-) This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > 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. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 13:34:19 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 10:34:19 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A3897F.7020203@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> Hi Tim, On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > Hopefully, when the KDP is working Rob will merge (and if necessary > debug) my changes & commit them to fix both problems. Ideally adding > the page optimization, but beggars can't be choosers. If he doesn't > I'll try to get to that later (if I have commit access to simh on github). You don't need commit access to the core repository on Github to get your changes submitted and accepted. The github paradigm is: 1) you create a personal account on github. 2) you 'clone' the github simh/simh repository to your personal github space. 3) you clone either of these to your working environment and do your work and check-in locally as desired/needed. 4) you configure your local repo to have your personal github repo as the primary push repo and the siimh/simh one as another remote repository. Steps 2 and 3 can be in any order. When you are ready to submit your changes, you: 1) you pull from the simh/simh and merge to the latest codebase 2) you push your local working repo to your personal github repo 3) Using the github web UI you create a pull request for the github simh/simh repo. This pull request will create an issue which will track the details of what will happen. I'll review the changes and either accept them as is and simply complete the merge or I'll respond with some comments and/or suggestions and you can make revisions until we're both happy and the merge will be completed. Once the merge completes, each of your commits (with your name) will be part of the repository/history. If you don't want to climb the learning curve of using git, I'll be glad to take changes which I'd prefer be the complete files of any files you've changed along with a description (as verbose as you may want) of the point of the changes and I'll review and commit these using the description as the commit message. I'll credit you in the commit comments, but the commit will have my name on it. If you go down this path, you can send all of the files as separate attachments or preferably bundle them in a zip file and send it via email (there is no problem is you include extra files which you didn't actually change since git will only notice the changed content anyway). Without regard to climbing the git learning curve, If you create a github account and let me know you've done it, I'll add you as a contributor to the project and assign issues to you where appropriate. If you create a github account now, and create an issue at https://github.com/simh/simh/issues describing the problems with Map_WriteW, I'll assign that issue to you and when you ultimately submit fixes, the pull request you create can be the fix to the issue... > I suppose I should see about building a current version, as I seem to be > in the middle of debugging several things by Braille... (Or is this > simply a memory test for me :-) Without jumping into git, you can always pickup the latest code at https://github.com/simh/simh/archive/master.zip I look forward to anything you've got to offer. Thanks. - Mark > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > 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. > > > From aek at bitsavers.org Mon May 27 14:47:44 2013 From: aek at bitsavers.org (Al Kossow) Date: Mon, 27 May 2013 11:47:44 -0700 Subject: [Simh] Speaking of cards In-Reply-To: <51A36F63.9050609@bitsavers.org> References: <51A36A38.3060106@ieee.org> <51A36F63.9050609@bitsavers.org> Message-ID: <51A3AA50.9070601@bitsavers.org> On 5/27/13 7:36 AM, Al Kossow wrote: > On 5/27/13 7:14 AM, Timothe Litt wrote: > >> I have some blank punch cards, I should scan one as it only comes with some customized images. >> > > I can make a high resolution scan of a buff 5081 if it's needed. > I just uploaded a scan of four different 5081 style cards to http://bitsavers.org/pdf/ibm/punchedCard/Card_Scans it will take an hour or two for it to get out to the mirrors From litt at ieee.org Mon May 27 15:12:19 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 15:12:19 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A3AA50.9070601@bitsavers.org> References: <51A36A38.3060106@ieee.org> <51A36F63.9050609@bitsavers.org> <51A3AA50.9070601@bitsavers.org> Message-ID: <51A3B013.3020004@ieee.org> Al, Thanks. I'll look for them. I just figured out how to scan and convert so the size comes out right, which was non trivial. I scanned at 100dpi (close to screen resolution), used imagemagick's convert -colors 256 in.png out.xpm. I couldn't get resize or resample or any other permutations to produce the right size from higher resolution scans. Anyhow, I've added one pink and one Harvard card. Do you want the scans for your collection? In one case I had to unpunch a few holes...sorta like the scotch tape I used to use with chad and the duplicator when I was desperate. But easier :-) I'll add yours and will see if the originator wants to take the changes; else I guess it will go to tools of simh. I also found some detailed reference material on the 029; there's a lot to do for a reasonable emulation. I'd forgotten that they did check digits of fields with relay logic! I'll ping the author (said he wanted feedback/suggestions, but that was 10 years ago!). If he's no longer interested, I may play some, or just post the task list to the list and see if someone else bites. In any case, I'm pretty sure I don't have the skills to wrap an X-windows image of an arbitrary drum card around a cylinder and rotate it while the machine works. Hopefully I won't spend the night sneezing from all the dust this has kicked up. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 14:47, Al Kossow wrote: > On 5/27/13 7:36 AM, Al Kossow wrote: >> On 5/27/13 7:14 AM, Timothe Litt wrote: >> >>> I have some blank punch cards, I should scan one as it only comes >>> with some customized images. >>> >> >> I can make a high resolution scan of a buff 5081 if it's needed. >> > > I just uploaded a scan of four different 5081 style cards to > http://bitsavers.org/pdf/ibm/punchedCard/Card_Scans > > it will take an hour or two for it to get out to the mirrors > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 15:24:28 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 15:24:28 -0400 Subject: [Simh] card reader and running commands In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> Message-ID: <51A3B2EC.70305@ieee.org> RE: the 'what commands should we be able to do without stopping the simulator' discussion: Based on this, "set cr reset" is one of them that we didn't think of before. (Or at least, I didn't.) This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 15:00, Jordi Guillaumes i Pons wrote: > El 27/05/2013, a les 18:09, Timothe Litt va escriure: > >> simh says 'not attached' You need to attach it at the simh prompt to a file of card images. > Oh, yes, I'm aware of that. I attached CR to a file with this content: > > $JOB OPERATOR > $PASSWORD ****** > ! Obtencio llistat de directoris > ! > INICI:: > . DEL DIR.LST > . DEL DIRDIZ.DAT > . DEL DIRSIZ.LST > ! > P010:: > . CHKPNT P010 > . R DIRECT > * DIR.LST=[*,*,*,*,*]*.* > * ^Z > P020:: > . CHKPNT P020 > . RUN DIRSZ1 > P030:: > . CHKPNT P030 > . RUN DIRSZ2 > . TYPE DIRSIZ.LST > $EOJ > > Never mind the comments and the programs, those WORK when I submit this file using the SUBMIT command. Then I do a SET CR RESET (as directed by the simh docs... it works for VMS and RSX :)) and... nothing happens. > > The card reader is indeed seen by the operating system: > > CONFIG>show hardWARE-CONFIGURATION (of system) /unit-record > CONFIG> > 20:56:52 CONFIG -- SHOW HARDWARE-CONFIGURATION -- > > > Unit Record Device Configuration > > Card reader configuration: > Device CPU > ------ --- > CDR0 0 > > Line printer configuration: > Device CPU Type Status > ------ --- ----- ------ > LPT0 0 LP20 Online > > It looks like everything is OK, but it does not work. That is the reason why I think there is some bug in the CD11 implementation in the simh side. > > > Jordi Guillaumes i Pons > jg at jordi.guillaumes.name > HECnet: BITXOV::JGUILLAUMES > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 15:36:18 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 12:36:18 -0700 Subject: [Simh] card reader and running commands In-Reply-To: <51A3B2EC.70305@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2EC.70305@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 12:24 PM, Timothe Litt wrote: > RE: the 'what commands should we be able to do without stopping the > simulator' discussion: > > Based on this, "set cr reset" is one of them that we didn't think of > before. (Or at least, I didn't.) This will work just fine with the remote console support currently available in the current simh code base at github. The Remote Console Facility allows a TELNET Connection to a user designated port so that some out of band commands can be entered to manipulate and/or adjust a running simulator. The commands which enable and control this capability are SET REMOTE TELNET=port, SET REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. The remote console facility has two modes of operation: 1) single command mode. and 2) multiple command mode. In single command mode you enter one command at a time and aren't concerned about what the simulated system is doing while you enter that command. The command is executed once you've hit return. In multiple command mode you initiate your activities by entering the WRU character (usually ^E). This will suspend the current simulator execution. You then enter commands as needed and when you are done you enter a CONTINUE command. While entering Multiple Command commands, if you fail to enter a complete command before the timeout (specified by "SET REMOTE TIMEOUT=seconds"), a CONTINUE command is automatically processed and simulation proceeds. A subset of normal simh commands are available for use in remote console sessions. The Single Command Mode commands are: ATTACH, DETACH, PWD, SHOW, DIR, LS, ECHO, HELP The Multiple Command Mode commands are: EXAMINE, IEXAMINE, DEPOSIT, EVALUATE, ATTACH, DETACH, ASSIGN, DEASSIGN, STEP, CONTINUE, PWD, SAVE, SET, SHOW, DIR, LS, ECHO, HELP > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 27-May-13 15:00, Jordi Guillaumes i Pons wrote: > > El 27/05/2013, a les 18:09, Timothe Litt va escriure: > > > >> simh says 'not attached' You need to attach it at the simh prompt to a file > of card images. > > Oh, yes, I'm aware of that. I attached CR to a file with this content: > > > > $JOB OPERATOR > > $PASSWORD ****** > > ! Obtencio llistat de directoris > > ! > > INICI:: > > . DEL DIR.LST > > . DEL DIRDIZ.DAT > > . DEL DIRSIZ.LST > > ! > > P010:: > > . CHKPNT P010 > > . R DIRECT > > * DIR.LST=[*,*,*,*,*]*.* > > * ^Z > > P020:: > > . CHKPNT P020 > > . RUN DIRSZ1 > > P030:: > > . CHKPNT P030 > > . RUN DIRSZ2 > > . TYPE DIRSIZ.LST > > $EOJ > > > > Never mind the comments and the programs, those WORK when I submit > this file using the SUBMIT command. Then I do a SET CR RESET (as directed by > the simh docs... it works for VMS and RSX :)) and... nothing happens. > > > > The card reader is indeed seen by the operating system: > > > > CONFIG>show hardWARE-CONFIGURATION (of system) /unit-record > > CONFIG> > > 20:56:52 CONFIG -- SHOW HARDWARE-CONFIGURATION -- > > > > > > Unit Record Device Configuration > > > > Card reader configuration: > > Device CPU > > ------ --- > > CDR0 0 > > > > Line printer configuration: > > Device CPU Type Status > > ------ --- ----- ------ > > LPT0 0 LP20 Online > > > > It looks like everything is OK, but it does not work. That is the reason why I > think there is some bug in the CD11 implementation in the simh side. > > > > > > Jordi Guillaumes i Pons > > jg at jordi.guillaumes.name > > HECnet: BITXOV::JGUILLAUMES > > > > > > > > > From jg at jordi.guillaumes.name Mon May 27 16:11:53 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 22:11:53 +0200 Subject: [Simh] card reader and running commands In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm va escriure: > The Remote Console Facility allows a TELNET Connection to a user designated port so that some out of band commands can be entered to manipulate and/or adjust a running simulator. The commands which enable and control this capability are SET REMOTE TELNET=port, SET REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. Hi Mark, The remote console addition is really useful! (It would justify upgrading simh to 4.0 by itself, in my opinion). I, however, have a suggestion: could you add a command to disconnect the telnet session? Right now the only way is to break into TELNET command mode and CLOSE the connection there... Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From Mark at infocomm.com Mon May 27 16:25:13 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 13:25:13 -0700 Subject: [Simh] card reader and running commands In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DB@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:12 PM, Jordi wrote: > El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm > va escriure: > > > The Remote Console Facility allows a TELNET Connection to a user > designated port so that some out of band commands can be entered to > manipulate and/or adjust a running simulator. The commands which enable > and control this capability are SET REMOTE TELNET=port, SET REMOTE > CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. > > Hi Mark, > > The remote console addition is really useful! (It would justify upgrading simh > to 4.0 by itself, in my opinion). I, however, have a suggestion: could you add a > command to disconnect the telnet session? Right now the only way is to > break into TELNET command mode and CLOSE the connection there... Hmmm... You have to do the same thing to disconnect from any console session.... This seems easy enough... From robert.jarratt at ntlworld.com Mon May 27 16:42:41 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 21:42:41 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> Message-ID: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Mark, It is time for me to start learning about git. The bit I am struggling to understand right now is now to clone your repository to my personal space on github, can I do this from the web site? Regards Rob > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 18:34 > To: Timothe Litt; Mark Pizzolato - Info Comm > Cc: Robert Jarratt; simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Hi Tim, > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > Hopefully, when the KDP is working Rob will merge (and if necessary > > debug) my changes & commit them to fix both problems. Ideally adding > > the page optimization, but beggars can't be choosers. If he doesn't > > I'll try to get to that later (if I have commit access to simh on github). > > You don't need commit access to the core repository on Github to get your > changes submitted and accepted. The github paradigm is: > 1) you create a personal account on github. > 2) you 'clone' the github simh/simh repository to your personal github > space. > 3) you clone either of these to your working environment and do your work > and check-in locally as desired/needed. > 4) you configure your local repo to have your personal github repo as the > primary push repo and the siimh/simh one as another remote repository. > Steps 2 and 3 can be in any order. > When you are ready to submit your changes, you: > 1) you pull from the simh/simh and merge to the latest codebase > 2) you push your local working repo to your personal github repo > 3) Using the github web UI you create a pull request for the github > simh/simh repo. This pull request will create an issue which will track the > details of what will happen. > I'll review the changes and either accept them as is and simply complete the > merge or I'll respond with some comments and/or suggestions and you can > make revisions until we're both happy and the merge will be completed. > Once the merge completes, each of your commits (with your name) will be > part of the repository/history. > > If you don't want to climb the learning curve of using git, I'll be glad to take > changes which I'd prefer be the complete files of any files you've changed > along with a description (as verbose as you may want) of the point of the > changes and I'll review and commit these using the description as the commit > message. I'll credit you in the commit comments, but the commit will have > my name on it. If you go down this path, you can send all of the files as > separate attachments or preferably bundle them in a zip file and send it via > email (there is no problem is you include extra files which you didn't actually > change since git will only notice the changed content anyway). > > Without regard to climbing the git learning curve, If you create a github > account and let me know you've done it, I'll add you as a contributor to the > project and assign issues to you where appropriate. If you create a github > account now, and create an issue at https://github.com/simh/simh/issues > describing the problems with Map_WriteW, I'll assign that issue to you and > when you ultimately submit fixes, the pull request you create can be the fix > to the issue... > > > I suppose I should see about building a current version, as I seem to > > be in the middle of debugging several things by Braille... (Or is > > this simply a memory test for me :-) > > Without jumping into git, you can always pickup the latest code at > https://github.com/simh/simh/archive/master.zip > > I look forward to anything you've got to offer. > > Thanks. > > - Mark > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > 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. > > > > > From toby at telegraphics.com.au Mon May 27 16:51:18 2013 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 27 May 2013 16:51:18 -0400 Subject: [Simh] Starting with git/github - Re: TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Message-ID: <51A3C746.3000202@telegraphics.com.au> On 27/05/13 4:42 PM, Robert Jarratt wrote: > Mark, > > It is time for me to start learning about git. The bit I am struggling to > understand right now is now to clone your repository to my personal space on > github, can I do this from the web site? Yes, the operation is called "Fork". "Cloning" is when you create a local copy (e.g. with git clone on CLI). --Toby > > Regards > > Rob > From Mark at infocomm.com Mon May 27 16:53:44 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 13:53:44 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > Mark, > > It is time for me to start learning about git. The bit I am struggling to > understand right now is now to clone your repository to my personal space > on github, can I do this from the web site? Yes. Cloning is both a concept and a raw git command you can use on the command line at a shell prompt. The command: $ git clone git://github.com/simh/simh.git This will create a local repository copy of the simh github repository. I use "Git Extensions" on my windows desktop as a git GUI. The Git Extensions interface has a clone GUI as well. It also provides a "bash shell" which you can enter direct git commands if/when you need to do this. Meanwhile, the github site's interface at https://github.com/simh/simh has a "Fork" button in the upper right hand corner. This fork operation creates a clone of the repository in your personal github account. Please ask as many questions as you want. The more you know the easier it will be for you to climb this hill.. Good Luck, - Mark > Regards > > Rob > > > -----Original Message----- > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > Sent: 27 May 2013 18:34 > > To: Timothe Litt; Mark Pizzolato - Info Comm > > Cc: Robert Jarratt; simh at trailing-edge.com > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > Hi Tim, > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > Hopefully, when the KDP is working Rob will merge (and if necessary > > > debug) my changes & commit them to fix both problems. Ideally > > > adding the page optimization, but beggars can't be choosers. If he > > > doesn't I'll try to get to that later (if I have commit access to > > > simh on > github). > > > > You don't need commit access to the core repository on Github to get > > your changes submitted and accepted. The github paradigm is: > > 1) you create a personal account on github. > > 2) you 'clone' the github simh/simh repository to your personal > > github space. > > 3) you clone either of these to your working environment and do your > work > > and check-in locally as desired/needed. > > 4) you configure your local repo to have your personal github repo > > as > the > > primary push repo and the siimh/simh one as another remote repository. > > Steps 2 and 3 can be in any order. > > When you are ready to submit your changes, you: > > 1) you pull from the simh/simh and merge to the latest codebase > > 2) you push your local working repo to your personal github repo > > 3) Using the github web UI you create a pull request for the github > > simh/simh repo. This pull request will create an issue which will > > track > the > > details of what will happen. > > I'll review the changes and either accept them as is and simply > > complete > the > > merge or I'll respond with some comments and/or suggestions and you > > can make revisions until we're both happy and the merge will be > completed. > > Once the merge completes, each of your commits (with your name) will > > be part of the repository/history. > > > > If you don't want to climb the learning curve of using git, I'll be > > glad > to take > > changes which I'd prefer be the complete files of any files you've > > changed along with a description (as verbose as you may want) of the > > point of the changes and I'll review and commit these using the > > description as the > commit > > message. I'll credit you in the commit comments, but the commit will > > have my name on it. If you go down this path, you can send all of the > > files as separate attachments or preferably bundle them in a zip file > > and send it > via > > email (there is no problem is you include extra files which you didn't > actually > > change since git will only notice the changed content anyway). > > > > Without regard to climbing the git learning curve, If you create a > > github account and let me know you've done it, I'll add you as a > > contributor to > the > > project and assign issues to you where appropriate. If you create a > github > > account now, and create an issue at > > https://github.com/simh/simh/issues > > describing the problems with Map_WriteW, I'll assign that issue to > > you > and > > when you ultimately submit fixes, the pull request you create can be > > the > fix > > to the issue... > > > > > I suppose I should see about building a current version, as I seem > > > to be in the middle of debugging several things by Braille... (Or > > > is this simply a memory test for me :-) > > > > Without jumping into git, you can always pickup the latest code at > > https://github.com/simh/simh/archive/master.zip > > > > I look forward to anything you've got to offer. > > > > Thanks. > > > > - Mark > > > > > This communication may not represent my employer's views, if any, on > > > the matters discussed. > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > 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. > > > > > > > > > From robert.jarratt at ntlworld.com Mon May 27 17:41:56 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 22:41:56 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> Message-ID: <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> Ah, I wondered if that is what you meant. Perhaps it would be a good idea to post something on GitHub (if there is a suitable place), to give newbies guidance on how to get set up. Any questions people ask could go in a FAQ, then you don't have to keep repeating yourself... :-) How are we going to manage Visual Studio Projects though? As you know, I use Visual Studio 2012 Express edition, so when I add files to the project, the project file will be in 2012 format, but the master is in an older format (2008 iirc). Won't we get into versioning conflicts? Regards Rob > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 21:54 > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > Mark, > > > > It is time for me to start learning about git. The bit I am struggling > > to understand right now is now to clone your repository to my personal > > space on github, can I do this from the web site? > > Yes. Cloning is both a concept and a raw git command you can use on the > command line at a shell prompt. The command: > > $ git clone git://github.com/simh/simh.git > > This will create a local repository copy of the simh github repository. I use > "Git Extensions" on my windows desktop as a git GUI. The Git Extensions > interface has a clone GUI as well. It also provides a "bash shell" which you > can enter direct git commands if/when you need to do this. > > Meanwhile, the github site's interface at https://github.com/simh/simh has a > "Fork" button in the upper right hand corner. This fork operation creates a > clone of the repository in your personal github account. > > Please ask as many questions as you want. The more you know the easier it > will be for you to climb this hill.. > > Good Luck, > > - Mark > > > Regards > > > > Rob > > > > > -----Original Message----- > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > Sent: 27 May 2013 18:34 > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > Hi Tim, > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > necessary > > > > debug) my changes & commit them to fix both problems. Ideally > > > > adding the page optimization, but beggars can't be choosers. If > > > > he doesn't I'll try to get to that later (if I have commit access > > > > to simh on > > github). > > > > > > You don't need commit access to the core repository on Github to get > > > your changes submitted and accepted. The github paradigm is: > > > 1) you create a personal account on github. > > > 2) you 'clone' the github simh/simh repository to your personal > > > github space. > > > 3) you clone either of these to your working environment and do > > > your > > work > > > and check-in locally as desired/needed. > > > 4) you configure your local repo to have your personal github repo > > > as > > the > > > primary push repo and the siimh/simh one as another remote repository. > > > Steps 2 and 3 can be in any order. > > > When you are ready to submit your changes, you: > > > 1) you pull from the simh/simh and merge to the latest codebase > > > 2) you push your local working repo to your personal github repo > > > 3) Using the github web UI you create a pull request for the > > > github simh/simh repo. This pull request will create an issue which > > > will track > > the > > > details of what will happen. > > > I'll review the changes and either accept them as is and simply > > > complete > > the > > > merge or I'll respond with some comments and/or suggestions and you > > > can make revisions until we're both happy and the merge will be > > completed. > > > Once the merge completes, each of your commits (with your name) will > > > be part of the repository/history. > > > > > > If you don't want to climb the learning curve of using git, I'll be > > > glad > > to take > > > changes which I'd prefer be the complete files of any files you've > > > changed along with a description (as verbose as you may want) of the > > > point of the changes and I'll review and commit these using the > > > description as the > > commit > > > message. I'll credit you in the commit comments, but the commit > > > will have my name on it. If you go down this path, you can send all > > > of the files as separate attachments or preferably bundle them in a > > > zip file and send it > > via > > > email (there is no problem is you include extra files which you > > > didn't > > actually > > > change since git will only notice the changed content anyway). > > > > > > Without regard to climbing the git learning curve, If you create a > > > github account and let me know you've done it, I'll add you as a > > > contributor to > > the > > > project and assign issues to you where appropriate. If you create a > > github > > > account now, and create an issue at > > > https://github.com/simh/simh/issues > > > describing the problems with Map_WriteW, I'll assign that issue to > > > you > > and > > > when you ultimately submit fixes, the pull request you create can be > > > the > > fix > > > to the issue... > > > > > > > I suppose I should see about building a current version, as I seem > > > > to be in the middle of debugging several things by Braille... (Or > > > > is this simply a memory test for me :-) > > > > > > Without jumping into git, you can always pickup the latest code at > > > https://github.com/simh/simh/archive/master.zip > > > > > > I look forward to anything you've got to offer. > > > > > > Thanks. > > > > > > - Mark > > > > > > > This communication may not represent my employer's views, if any, > > > > on the matters discussed. > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > 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. > > > > > > > > > > > > > From Mark at infocomm.com Mon May 27 18:03:32 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 15:03:32 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 2:42 PM, Robert Jarratt wrote: > Ah, I wondered if that is what you meant. Perhaps it would be a good idea to > post something on GitHub (if there is a suitable place), to give newbies > guidance on how to get set up. Any questions people ask could go in a FAQ, > then you don't have to keep repeating yourself... :-) Good point. Let me think about how/where to keep this info. > How are we going to manage Visual Studio Projects though? As you know, I > use Visual Studio 2012 Express edition, so when I add files to the project, the > project file will be in 2012 format, but the master is in an older format > (2008 iirc). Won't we get into versioning conflicts? Good question. Project definition files change very rarely. I would suggest that you DON'T check-in your changed projects. By default, the current repository is setup to not 'notice' new files (i.e. your .vcxproj files) in the Visual Studio Projects directory, so you really won't have to think much about this. When visual studio 'auto-converts' the default (Visual Studio 2008) projects to ones appropriate for your Visual Studio version, it will change the simh.sln file with pointers to the new project files. Git will notice this change since the simh.sln file is already managed under source control. When you do a commit/check-in, do not check-in the simh.sln file. As part of me pulling in your new code I'll find that it won't build cleanly in my test environment and I'll fix the base project files and ALSO go and update the makefile and descrip.mms to reflect the required corresponding changes. > > -----Original Message----- > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > Sent: 27 May 2013 21:54 > > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > > Cc: simh at trailing-edge.com > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > > Mark, > > > > > > It is time for me to start learning about git. The bit I am > > > struggling to understand right now is now to clone your repository > > > to my personal space on github, can I do this from the web site? > > > > Yes. Cloning is both a concept and a raw git command you can use on > > the command line at a shell prompt. The command: > > > > $ git clone git://github.com/simh/simh.git > > > > This will create a local repository copy of the simh github > > repository. I > use > > "Git Extensions" on my windows desktop as a git GUI. The Git > > Extensions interface has a clone GUI as well. It also provides a > > "bash shell" which > you > > can enter direct git commands if/when you need to do this. > > > > Meanwhile, the github site's interface at https://github.com/simh/simh > > has > a > > "Fork" button in the upper right hand corner. This fork operation > > creates > a > > clone of the repository in your personal github account. > > > > Please ask as many questions as you want. The more you know the > > easier it will be for you to climb this hill.. > > > > Good Luck, > > > > - Mark > > > > > Regards > > > > > > Rob > > > > > > > -----Original Message----- > > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > > Sent: 27 May 2013 18:34 > > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > > > Hi Tim, > > > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > > necessary > > > > > debug) my changes & commit them to fix both problems. Ideally > > > > > adding the page optimization, but beggars can't be choosers. If > > > > > he doesn't I'll try to get to that later (if I have commit > > > > > access to simh on > > > github). > > > > > > > > You don't need commit access to the core repository on Github to > > > > get your changes submitted and accepted. The github paradigm is: > > > > 1) you create a personal account on github. > > > > 2) you 'clone' the github simh/simh repository to your personal > > > > github space. > > > > 3) you clone either of these to your working environment and do > > > > your > > > work > > > > and check-in locally as desired/needed. > > > > 4) you configure your local repo to have your personal github > > > > repo as > > > the > > > > primary push repo and the siimh/simh one as another remote > repository. > > > > Steps 2 and 3 can be in any order. > > > > When you are ready to submit your changes, you: > > > > 1) you pull from the simh/simh and merge to the latest codebase > > > > 2) you push your local working repo to your personal github repo > > > > 3) Using the github web UI you create a pull request for the > > > > github simh/simh repo. This pull request will create an issue > > > > which will track > > > the > > > > details of what will happen. > > > > I'll review the changes and either accept them as is and simply > > > > complete > > > the > > > > merge or I'll respond with some comments and/or suggestions and > > > > you can make revisions until we're both happy and the merge will > > > > be > > > completed. > > > > Once the merge completes, each of your commits (with your name) > > > > will be part of the repository/history. > > > > > > > > If you don't want to climb the learning curve of using git, I'll > > > > be glad > > > to take > > > > changes which I'd prefer be the complete files of any files you've > > > > changed along with a description (as verbose as you may want) of > > > > the point of the changes and I'll review and commit these using > > > > the description as the > > > commit > > > > message. I'll credit you in the commit comments, but the commit > > > > will have my name on it. If you go down this path, you can send > > > > all of the files as separate attachments or preferably bundle them > > > > in a zip file and send it > > > via > > > > email (there is no problem is you include extra files which you > > > > didn't > > > actually > > > > change since git will only notice the changed content anyway). > > > > > > > > Without regard to climbing the git learning curve, If you create a > > > > github account and let me know you've done it, I'll add you as a > > > > contributor to > > > the > > > > project and assign issues to you where appropriate. If you create > > > > a > > > github > > > > account now, and create an issue at > > > > https://github.com/simh/simh/issues > > > > describing the problems with Map_WriteW, I'll assign that issue > > > > to you > > > and > > > > when you ultimately submit fixes, the pull request you create can > > > > be the > > > fix > > > > to the issue... > > > > > > > > > I suppose I should see about building a current version, as I > > > > > seem to be in the middle of debugging several things by > > > > > Braille... (Or is this simply a memory test for me :-) > > > > > > > > Without jumping into git, you can always pickup the latest code at > > > > https://github.com/simh/simh/archive/master.zip > > > > > > > > I look forward to anything you've got to offer. > > > > > > > > Thanks. > > > > > > > > - Mark > > > > > > > > > This communication may not represent my employer's views, if > > > > > any, on the matters discussed. > > > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > > 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. > > > > > > > > > > > > > > > > > > > From robert.jarratt at ntlworld.com Mon May 27 18:23:25 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 23:23:25 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> Message-ID: <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> Would I be able to check the solution and project files into my own repo and somehow avoid sending those commits to you, assuming I can keep them separate from the other changes? > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 23:04 > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > On Monday, May 27, 2013 at 2:42 PM, Robert Jarratt wrote: > > Ah, I wondered if that is what you meant. Perhaps it would be a good > > idea to post something on GitHub (if there is a suitable place), to > > give newbies guidance on how to get set up. Any questions people ask > > could go in a FAQ, then you don't have to keep repeating yourself... > > :-) > > Good point. Let me think about how/where to keep this info. > > > How are we going to manage Visual Studio Projects though? As you know, > > I use Visual Studio 2012 Express edition, so when I add files to the > > project, the project file will be in 2012 format, but the master is in > > an older format > > (2008 iirc). Won't we get into versioning conflicts? > > Good question. Project definition files change very rarely. I would suggest > that you DON'T check-in your changed projects. By default, the current > repository is setup to not 'notice' new files (i.e. your .vcxproj files) in the > Visual Studio Projects directory, so you really won't have to think much about > this. When visual studio 'auto-converts' the default (Visual Studio 2008) > projects to ones appropriate for your Visual Studio version, it will change the > simh.sln file with pointers to the new project files. Git will notice this change > since the simh.sln file is already managed under source control. When you > do a commit/check-in, do not check-in the simh.sln file. As part of me pulling > in your new code I'll find that it won't build cleanly in my test environment > and I'll fix the base project files and ALSO go and update the makefile and > descrip.mms to reflect the required corresponding changes. > > > > -----Original Message----- > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > Sent: 27 May 2013 21:54 > > > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > > > Cc: simh at trailing-edge.com > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > > > Mark, > > > > > > > > It is time for me to start learning about git. The bit I am > > > > struggling to understand right now is now to clone your repository > > > > to my personal space on github, can I do this from the web site? > > > > > > Yes. Cloning is both a concept and a raw git command you can use on > > > the command line at a shell prompt. The command: > > > > > > $ git clone git://github.com/simh/simh.git > > > > > > This will create a local repository copy of the simh github > > > repository. I > > use > > > "Git Extensions" on my windows desktop as a git GUI. The Git > > > Extensions interface has a clone GUI as well. It also provides a > > > "bash shell" which > > you > > > can enter direct git commands if/when you need to do this. > > > > > > Meanwhile, the github site's interface at > > > https://github.com/simh/simh has > > a > > > "Fork" button in the upper right hand corner. This fork operation > > > creates > > a > > > clone of the repository in your personal github account. > > > > > > Please ask as many questions as you want. The more you know the > > > easier it will be for you to climb this hill.. > > > > > > Good Luck, > > > > > > - Mark > > > > > > > Regards > > > > > > > > Rob > > > > > > > > > -----Original Message----- > > > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > > > Sent: 27 May 2013 18:34 > > > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > > > > > Hi Tim, > > > > > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > > > necessary > > > > > > debug) my changes & commit them to fix both problems. Ideally > > > > > > adding the page optimization, but beggars can't be choosers. > > > > > > If he doesn't I'll try to get to that later (if I have commit > > > > > > access to simh on > > > > github). > > > > > > > > > > You don't need commit access to the core repository on Github to > > > > > get your changes submitted and accepted. The github paradigm is: > > > > > 1) you create a personal account on github. > > > > > 2) you 'clone' the github simh/simh repository to your > > > > > personal github space. > > > > > 3) you clone either of these to your working environment and > > > > > do your > > > > work > > > > > and check-in locally as desired/needed. > > > > > 4) you configure your local repo to have your personal github > > > > > repo as > > > > the > > > > > primary push repo and the siimh/simh one as another remote > > repository. > > > > > Steps 2 and 3 can be in any order. > > > > > When you are ready to submit your changes, you: > > > > > 1) you pull from the simh/simh and merge to the latest codebase > > > > > 2) you push your local working repo to your personal github repo > > > > > 3) Using the github web UI you create a pull request for the > > > > > github simh/simh repo. This pull request will create an issue > > > > > which will track > > > > the > > > > > details of what will happen. > > > > > I'll review the changes and either accept them as is and simply > > > > > complete > > > > the > > > > > merge or I'll respond with some comments and/or suggestions and > > > > > you can make revisions until we're both happy and the merge will > > > > > be > > > > completed. > > > > > Once the merge completes, each of your commits (with your name) > > > > > will be part of the repository/history. > > > > > > > > > > If you don't want to climb the learning curve of using git, I'll > > > > > be glad > > > > to take > > > > > changes which I'd prefer be the complete files of any files > > > > > you've changed along with a description (as verbose as you may > > > > > want) of the point of the changes and I'll review and commit > > > > > these using the description as the > > > > commit > > > > > message. I'll credit you in the commit comments, but the commit > > > > > will have my name on it. If you go down this path, you can send > > > > > all of the files as separate attachments or preferably bundle > > > > > them in a zip file and send it > > > > via > > > > > email (there is no problem is you include extra files which you > > > > > didn't > > > > actually > > > > > change since git will only notice the changed content anyway). > > > > > > > > > > Without regard to climbing the git learning curve, If you create > > > > > a github account and let me know you've done it, I'll add you as > > > > > a contributor to > > > > the > > > > > project and assign issues to you where appropriate. If you > > > > > create a > > > > github > > > > > account now, and create an issue at > > > > > https://github.com/simh/simh/issues > > > > > describing the problems with Map_WriteW, I'll assign that issue > > > > > to you > > > > and > > > > > when you ultimately submit fixes, the pull request you create > > > > > can be the > > > > fix > > > > > to the issue... > > > > > > > > > > > I suppose I should see about building a current version, as I > > > > > > seem to be in the middle of debugging several things by > > > > > > Braille... (Or is this simply a memory test for me :-) > > > > > > > > > > Without jumping into git, you can always pickup the latest code > > > > > at https://github.com/simh/simh/archive/master.zip > > > > > > > > > > I look forward to anything you've got to offer. > > > > > > > > > > Thanks. > > > > > > > > > > - Mark > > > > > > > > > > > This communication may not represent my employer's views, if > > > > > > any, on the matters discussed. > > > > > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > From toby at telegraphics.com.au Mon May 27 20:54:14 2013 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 27 May 2013 20:54:14 -0400 Subject: [Simh] git branch/cherry-pick - Re: TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> Message-ID: <51A40036.6080206@telegraphics.com.au> On 27/05/13 6:23 PM, Robert Jarratt wrote: > Would I be able to check the solution and project files into my own repo and > somehow avoid sending those commits to you, assuming I can keep them > separate from the other changes? > Yes, you can cherry-pick the code-related commits to a branch and make a pull request on that branch only. --Toby From litt at ieee.org Tue May 28 11:54:19 2013 From: litt at ieee.org (Timothe Litt) Date: Tue, 28 May 2013 11:54:19 -0400 Subject: [Simh] KDP Documentation Message-ID: <51A4D32B.60800@ieee.org> I knew I had some documentation for the KMC/DUP combination, though I still haven't found the COMIOP/DUP manual (AA-5670A-TC) in my collection, or on-line. It may be on the -11 or VAX microfiche, but I've contributed my sets to CHM. Don't think they've been digitized. Anyhow, the following memo describes COM IOP-DUP at a high level, and describes in some detail how the KMC controls the DUP. It may be useful for your efforts. One note: "flag mode" as used here has nothing to do with the FLAG character of bit-stuffing protocols. It's a synonym for polled (v.s. interrupt-driven) IO. By the way, there also was COM IOP-DZ, which did similar things with the DZ11. COMMUNICATIONS IOP-DUP COMMUNICATIONS IOP-DUP Page 1-2 INTRODUCTION ------------ The sychronous communications options on the 2020 are comprised of a KMC11 and either one or two DUP11s. This combination can also be referred to as COMM IOP-DUP. The DUP11 forms an interface between a synchronous modem and the UNIBUS. Eight bit bytes of data are transferred to the DUP over the UNIBUS and are serialized and formatted for transmission. The format of the data stream is controlled by registers in the DUP which are read and written by either the CPU or a local IO Processor. (IOP) The 2020 utilizes the KMC11 as the local IOP for the DUP11. The KMC is a microprogrammed auxilliary microprocessor designed for communications functions. The microprogram in the KMC is held in a writable control store memory (CRAM 16 bits x 1K) which is loaded over the UNIBUS by the 2020. This allows changes in protocols etc. to be nearly transparent to the CPU. The KMC transfers data between 2020 memory and the DUP using DMA and NPR transfers. The DUP11 is operated in flag mode (interrupts disabled) and is interrogated by the KMC11 periodically to determine if the character being transmitted is done or if a character has been assembled by the receiver. This relieves the CPU of the extensive interrupt handling which would otherwise be necessary to maintain the synchronous data stream. REFERENCES ---------- 1. KMC11 Users Manual EK-KMC11-OP-001 2. COMM IOP-DUP Programming Manual AA-5670A-TC 3. DSKMA Diagnostic Microfiche AH-E373A-DD 4. DSDUA Diagnostic Microfiche AH-E371A-DD 5. DUP11 Maintenance Manual EK-DUP11-MM-002 6. KS10 Maintenance Guide EK-OKS10-MG-001 7. Terminals and Communications Handbook COMM IOP-DUP Page 1-3 KMC11 The functional operation of the KMC11 is totally dependent on the microcode internal to the unit. Since this microcode is in a writable control store, no attempt will be made to present internal operations of the KMC11 in this course. We will deal with the functional interface between the KMC11, DUP11, and the UNIBUS. The KMC11 has 4 UNIBUS addressable registers. (REFER to Fig. 1) All communications between the CPU and the KMC11 are accomplished using these registers. The KMC11 views these as 8 byte size registers.(BSEL 0-7, addresses 76XXX0-7) They appear to the UNIBUS as 4, word or byte addressable, registers.(SEL 0, 2, 4, and 6) Only the high byte of register SEL 0 (BSEL 1) has a fixed function. This is the Maintenance Register. The remainder of the UNIBUS register functions are controlled by the KMC11 microcode and the CPU software. The Maintenance Register can be used to alter the KMC11 internal data paths for loading the CRAM and for other maintenance functions. For most maintenance functions, the RUN bit of the maintenance Register will be cleared. This stops the microprocessor clock which allows the CPU to manipulate the UNIBUS registers without interference from the KMC11. Bit 10 of the maintenance register ,when set, causes the 10 low order bits of SEL 4 to be used as an address for CRAM. SEL 6 can then be used for either reading or writing the addressed CRAM location. The read or write is controlled by maintenance register bits 10 and 9 + 10 + 13 respectively. To access CRAM, the 2020 CPU will clear the RUN bit of the Maintenance Register. It will then load the desired CRAM address into bits 0 -> 9 of SEL 4. If the operation is to write CRAM, the CPU will load SEL 6 with the new CRAM data and write the Maintenance Register, setting bits 9, 10 and 13. This will cause the KMC11 to write the data in SEL 6 to the CRAM location specified by SEL 4 bits 0 -> 9. To read CRAM, the CPU will write the Maintenance Register bit 10. This will cause the data in the CRAM location specified by bits 0->9 of SEL 4 to be transferred to SEL 6. The CPU will then read SEL 6 to determine the contents of the CRAM location. The Maintenance Register can be used to single step through instructions supplied by the CPU, read CRAM, and single step through the microcode for diagnostic purposes. The KMC11 has its own internal memory (1k x 8 bits) which it uses for data storage and computation. This memory can not be used for instruction storage nor can the CRAM contents be modified by the KMC11. COMM IOP-DUP Page 1-4 KMC11 - UBA - MEMORY DATA TRANSFER The KMC11 receives commands from the CPU through it's UNIBUS registers. The microcode interprets the command and then takes the proper actions to process the command. The KMC11 can also send commands to the CPU by writing it's UNIBUS registers and posting an interrupt to the UNIBUS. There are 3 commands which must occur before transmit and receive operations can take place. 1. INITIALIZATION; This command must be performed after loading KMC11 microcode to initiate operation. 2. A BASE IN command for each DUP11; This command informs the KMC of the line number assignment and CSR base address of each DUP11. 3. A CONTROL IN command for each DUP11; This command sets up the line parameters for each DUP11 and the polling rate to be used in interrogating the DUP CSRs. The COMM IOP-DUP handles the modem handshaking and monitoring with the exception of the RING and CARRIER lines. The COMM IOP-DUP does all of the memory to transmitter and receiver to memory data handling. The CPU informs the COMM IOP-DUP of the areas in memory to be used for transmit and receive data. This is done through BUFFER DESCRIPTOR LISTS for each transmit and receive channel. Each buffer descriptor list points to the start of a series of 3 word (16 bit word length) buffer descriptors in contiguous memory locations. Each buffer descriptor contains; a starting address for the buffer, a byte count, and control fields for the starting and stopping of messages etc.. The buffers may be scattered throughout main memory with the descriptors pointing to them. The major requirement is that the buffer descriptor list be in a series of continuous memory locations. Up to 2 lists may be sent to the KMC11 for each transmit and receive line. The lists are sent to the COMM IOP-DUP when the CPU desires to transmit or receive messages. This is done with a BUFFER ADDRESS IN command. This command has the starting address of the buffer descriptor list, the line number the list applies to, and a bit controlling whether it is a transmit or receive buffer. NOTE The CPU will also have to set up the UBA pager for the buffer areas in memory for address translation from 18 bit UNIBUS to KS10 addressing. The KMC11 uses the buffer descriptor lists to set up it's DMA addressing for each transmit and receive line. Once the lists are in the KMC11, the actual data transfer operations are transparent to the CPU. NOTE All transfers initiated by the KMC11 over the UNIBUS are NPRs. The only time the KMC11 "talks" to the 2020 CPU is when the CPU writes the KMCs registers, or when posting an interrupt on the UNIBUS. COMM IOP-DUP Page 1-5 KMC11 - UBA - MEMORY DATA TRANSFER TRANSMIT -------- NOTE The following description is for DDCMP operation of the COMM IOP-DUP. The CPU will compile the message to be sent in memory and transfer the buffer descriptor list to the KMC11. The KMC11 receives the buffer descriptor list with the command to transmit and retreives the first buffer descriptor from memory. The KMC then does the required handshaking with the modem via the RXCSR register of the DUP11. The KMC initiates the message by setting the SEND bit in TXCSR of the DUP and transferring a SYNC character and the TSOM bit to the TXDBUF. As each character is transferred from the TXDBUF to the transmitter shift register in the DUP, TXDONE will be set in TXCSR. The KMC checks the TXCSR for TXDONE by periodically reading the register. The rate at which the DUP11 registers are polled by the KMC is controlled by one of the set up commands sent to the KMC by the CPU at system initialization. When the KMC detects TXDONE, it will transfer another character to the TXDBUF of the DUP. This will continue until 8 SYNC characters have been transferred, when the KMC will reset the TSOM bit. NOTE The COMM IOP-DUP microcode in the KMC11 can send 8 sync characters automatically in DDCMP mode, depending on a control bit within the buffer descriptor. If the control bit is not set, the sync characters (if any) must be included with the message. At this point the KMC will begin transferring message data from 2020 memory using NPRs. The transfer sequence is similar to the NPR slow mode transfer used for the tape unit, but 36 bit mode is not set. As each data word is received from the system, the KMC places it in it's internal memory and waits for TXDONE to set. When the KMC detects TXDONE on a polling cycle, it transfers an 8 bit character to the DUP TXDBUF register using a byte mode NPR. This process is repeated until the number of characters transferred is equal to the byte count within the buffer descriptor. Depending on the state of control bits in the buffer descriptor , the KMC will either; start transmitting data from a second buffer descriptor or buffer descriptor list and interrupt the CPU , or terminate the message. When the last character of the message is transferred to the DUP, the KMC will set the TEOM bit in the TXCSR. This causes the accumulated CRC to be transmitted immediately after the last character. A second message may start immediately after the first, using another buffer descriptor or buffer descriptor list. Messages may be strung together this way until no buffer descriptor list is pending in the KMC. Alternately, a message may be distributed among several buffer descriptors or descriptor lists, terminating only when the bit, in the buffer descriptor, controlling the setting of the TEOM bit, is set. COMM IOP-DUP Page 1-6 KMC11 - UBA - MEMORY DATA TRANSFER RECEIVE ------- NOTE The following discussion assumes that the COMM IOP-DUP has been initialized and that DDCMP is the protocol. The COMM IOP-DUP receive operation is initiated when the CPU assigns a buffer descriptor list or lists to a receive line. The buffer descriptor list tells the KMC11 where in memory to place received data. If data is received by the DUP11 and no buffer descriptor list is assigned, the COMM IOP-DUP will post an error to the CPU via an interrupt. When the first non-sync character is received and in the RXDBUF, the DUP11 sets RXDONE. This is detected by the KMC11 on the next polling cycle and the character is transferred to the KMC with a byte mode NPR. If the first character following the leading sync characters is not an SOH, ENQ or DLE character the associated DUP11 is resynchronized. In this case no interrupt is sent to the CPU. The KMC will assemble the characters into 16 bit words for transfer to main memory. As each word is assembled, the KMC will issue an NPR transfer, through the UBA, to main memory. The transfer sequence resembles the NPR slow mode transfers used for tape system data transfer with 36 bit mode disabled. The first six bytes in DDCMP protocol are the HEADER. This is treated as a discrete message by the hardware and CRC is done on these six bytes. If a header CRC error occurs, the KMC aborts reception, posts an error interrupt to the CPU, and resumes searching for sync characters. The HEADER is analyzed by the KMC11 for the BYTE COUNT and the DDCMP quick sync bit. The byte count allows the KMC to discern the message CRC characters from the last data character in the message. If the quick sync bit is set, the KMC will place the applicable DUP11 in sync search mode immediately following the end of the message. If the quick sync bit is not set, the KMC11 assumes the next message is either abutted to the current message or is preceded by at least 8 sync characters. The KMC will continue transferring data from the DUP at each assertion of RXDONE, assembling 16 bit words, and transferring the words to memory until the number of bytes received equals the byte count in the header. The KMC11 will not post a completion interrupt to the CPU until the entire message has been received unless the message is larger than the currently assigned message buffer. If the message is larger than the current buffer, the KMC will post an interrupt to the CPU and continue transferring data to the next buffer defined in the buffer descriptor list. When the last character of the message has been received, the KMC will check the CRC and do one of three things: 1. If CRC was bad, the KMC will post an error interrupt to the CPU and immediately enter sync search mode. 2. If CRC was good and the quick sync bit was set in the header, the KMC will start looking for another message preceded by less than 8 sync characters. 3. If CRC was good and the quick sync bit wasn't set, the KMC will examine the next character after the CRC and, if it is a start of header (SOH), continue reception of the next message, placing the data in the next buffer. COMM IOP-DUP Page 1-7 KMC11 - UBA - MEMORY DATA TRANSFER There are two output commands issued by the KMC11 to the CPU. The first is a CONTROL OUT command and is used in posting error conditions to the CPU. The second is the BUFFER ADDRESS OUT command used to indicate that that a buffer assigned by a buffer descriptor has been filled or its' contents transmitted. The buffer address out command is also used when a complete message has been received, whether or not it has filled a buffer. In any case, the KMC will shift its' memory NPR operations to the next buffer in the buffer descriptor list or to the next buffer descriptor list as applicable. COMM IOP-DUP Page 1-8 DUP11 INTRODUCTION ------------ The DUP11, together with the KMC11, forms a synchronous communications subsystem for the 2020. High speed synchronous communications capability allows the 2020 to be used in computer networking applications such as DECNET. This type of application may be a major factor in a buyer's decision on which computer system he will purchase. BASIC BLOCK FUNCTIONS --------------------- The DUP11 basic block can be broken down into three major areas; 1. THE UNIBUS INTERFACE comprised of the UNIBUS tranceivers, the interrupt control logic, the address select logic, the reset logic, and the UNIBUS multiplexer. 2. THE REGISTERS AND CONTROL LOGIC comprised of the five registers and part of the TX control and RX control logic. 3. THE MODEM INTERFACE comprised of the remainder of the TX control and RX control logic and the clock logic. UNIBUS INTERFACE ---------------- This section of the DUP11 is responsible for getting data into and out of the unit to the UNIBUS. The address select logic decodes the UNIBUS address lines and determines if the address on the lines matches the switch settings on the DUP11 and what type of data cycle is required. The interrupt control logic will issue a BR when conditions internal to the DUP11 require processor intervention. The interrupt logic can be enabled or disabled under software control. The reset logic initializes the DUP11 when a UNIBUS initialize signal occurs. The reset logic will also initialize the DUP11 under software control when TXCSR bit 8 is set. The UNIBUS tranceivers and multiplexer receive and transmit data between the UNIBUS and the DUP11 registers under control of the address select logic. DUP11 REGISTERS --------------- There are 5 registers in the DUP11 which are used to control it's operation and communicate with the UNIBUS. 1. The RXCSR register is used to control the operation of the receiver section of the DUP11 and to interface with the modem. The register is R/W and is word and byte addressable. 2. The RXDBUF is a read only register which holds the received data in the low byte and status information in the high byte. The RXDBUF shares the same address with PACSR and is word addressable. 3. The PACSR is a write only register which controls the overall mode of the DUP11. This register contains the DEC mode bit, the bit which determines whether CRC is to be used or not, the secondary address mode bit, and either the secondary address or the SYNC character in the low byte. The PACSR and the RXDBUF share the same address and are word addressable only. COMM IOP-DUP Page 1-9 DUP11 4. The TXCSR register is used to control the operation of the transmitter section of the DUP11 and to control maintenance functions. The register is read/write and word and byte addressable. 5. The TXDBUF register contains the remainder of the control and status bits for the transmitter and the low byte holds the data to be transmitted. The register is word and byte addressable and is a read/write register. TX CONTROL LOGIC ---------------- The transmit control logic is responsible for: 1. Serializing data to be transmitted and transferring it to the modem. 2. Transmission of FLAG and ABORT sequences in bit oriented protocols. (DEC MODE reset) 3. Bit stuffing when in bit oriented protocols. 4. Signaling when the character currently being transmitted is done by setting TXDONE in TXCSR. 5. Computing CRC in either CRC-16 or CRC/CCITT format on transmitted data. RX CONTROL LOGIC ---------------- The receiver control logic is responsible for: LE;Synchronizing the receiver logic with the received signal. 1. Assembling the received serial data in the receiver shift register and transferring it to the RXDBUF. 2. Signaling when the latest assembled character is available in the RXDBUF by asserting RXDONE. 3. "Stripping" extra leading SYNC characters after synchronization when in DEC mode. LE;Deleting "stuffed" "0" bits from the data stream when not in DEC mode. 4. Detecting FLAG and ABORT sequences when not in DEC mode. 5. Checking received CRC characters against computed CRC characters in CRC-16 or CRC/CCITT formats. FUNCTIONAL DESCRIPTION ---------------------- The transmit operation of the DUP11 is somewhat dependent on whether a bit oriented protocol (SDLC type protocols) or a byte oriented protocol (DDCMP etc.) is being used. BYTE ORIENTED OPERATION (DDCMP and BISYNC) ------------------------------------------ For byte mode operation the DEC mode bit in PACSR must be set. This will cause the CRC circuits to use the CRC/16 format to check and generate CRC. This bit also controls whether "0" bits are "stuffed" into or stripped from a data stream containing more than 5 consecutive "1" bits. When the DEC mode bit is set, bit stuffing is not done. COMM IOP-DUP Page 1-10 DUP11 The CRC PAR INH bit in PACSR is used to enable or disable CRC generation or error detection. This bit will usually be set on BISYNC protocols and reset for DDCMP. All "handshaking" with the modem must be completed prior to the start of transmission. This is done through the RXCSR register. The "handshaking" is not automatic and must be done by the program. The insertion of Sync characters is also a program function. The DUP11 has no provision for automatically transmitting sync characters. Transmission begins when the program sets the SEND bit in TXCSR and loads a sync character into the TXDBUF along with the Transmit Start Of Message bit. All sync characters must be loaded by the program and the TSOM bit held asserted until the start of the last sync character. As each character is sent out, the TXDONE bit is set in TXCSR. The program will get another sync character, load it into TXDBUF and repeat until the proper number of sync characters have been sent. After the start of the last sync character the program will clear TSOM. At the next assertion of TXDONE the first data character will be loaded into TXDBUF and the CRC circuit will start to compute the CRC code for the data portion of the message. NOTE The CRC calculation can be inhibited by bit 09 of PACSR. This will usually be the case for BISYNC type protocols. The program will continue to load characters into the TXDBUF, at each transition of TXDONE, until the end of the message. When the last character is loaded, the TEOM bit will also be set by the program. This will cause the CRC check character to be transmitted immediately following the last data character. (If the CRC is enabled) BIT ORIENTED OPERATION (SDLC etc.) ---------------------------------- For operation in SDLC or other bit oriented protocols the DEC MODE bit in PACSR must be reset. This allows bit stuffing (The insertion of a "0" bit after each 5 consecutive "1" bits in a data stream of more than 5 consecutive "1" bits) to prevent confusing data with FLAG and ABORT sequences. The DEC MODE bit being reset also alters the CRC computation so that the CRC conforms to CRC/CCITT format. Some protocols may compute the CRC differently and if one of those is in use the CRC will be disabled using bit 09 of PARCSR. If CRC is disabled the program must compute any required CRC for the protocol in use. NOTE The following discussion assumes that all required "handshaking" with the modem has been completed and the DUP11 has been initialized. To start transmission, the SEND bit must be set in TXCSR and the TSOM bit in TXDBUF. This will cause an initial FLAG character to be transmitted. FLAGs will continue to be transmitted until the TSOM bit is reset. The transmission of FLAG characters in this mode is automatic and the characters do not have to be loaded into the TXDBUF by the processor. When the TSOM bit is reset, the TXDONE bit will be asserted at the conclusion of the character in transmission. COMM IOP-DUP Page 1-11 DUP11 When the program "sees" TXDONE, it will start transferring data to the TXDBUF. At each assertion of TXDONE, another character of data will be loaded. The CRC computation (if enabled) starts with the transfer of the first data to TXDBUF. The transmitter also enters the "transparent" state (bit stuffing is enabled) when the transmitter starts sending data. At the conclusion of the message the program sets the TEOM bit in TXDBUF and, at the end of the character being serialized, (if CRC is enabled) the CRC character is transmitted. At the conclusion of the CRC character a FLAG character is automatically transmitted. The program has three options at this point: SEND may be cleared, which allows the FLAG character to be completed and after a delay of 1 1/2 bit times the transmitter enters the IDLE state. TEOM may be held set, which will cause continuous FLAG characters to be transmitted. TEOM may be cleared and a second data message started without setting TSOM. The receiver section operates differently for byte oriented and bit oriented protocols and the two modes are discussed separately in the following section. BYTE ORIENTED RECEIVER (DDCMP, BISYNC etc.) ------------------------------------------- For BYTE mode operation, the DEC MODE bit and the SYNC character to be used must be loaded into the PACSR prior to enabling the receiver. The DEC MODE bit causes the low byte of PACSR to be recognized as a SYNC character, and the CRC circuitry of both the receiver and transmitter to use CRC-16 for generating and checking CRC. The STRIP SYNC bit of RXCSR may also be set, which allows SYNC characters occuring after receiver synchronization to be automatically deleted. Synchronization is considered complete when 2 succesive characters which match the low byte of PACSR have been recognized. The STRIP SYNC bit causes any other leading SYNC characters to be ignored. After the initialization and any needed modem handshaking has been done, the RCVEN bit in RXCSR may be set. This enables the receiver to search the incoming signals until 2 successive SYNC characters are detected. All characters following the detection of the 2 successive SYNC characters are interpreted as data. (Unless the STRIP SYNC bit is set, when it is the detection of the first non-SYNC character that will cause all following characters to be interpreted as data.) When this has occured, the RXACT bit will be asserted and the RXDONE bit set. (Also this will disable the STRIP SYNC logic until the receiver logic is reinitialized.) All data following the SYNC characters is included in the CRC calculation. For some protocols in the BISYNC family the CRC logic must be disabled due to possible control characters in the data field. Once RXDONE is set the program will read the assembled character in the RXBUF, reseting RXDONE. This process will repeat until the expected number of characters has been received. The program will then sample the CRC PAR ERR bit to determine if there was an error in the data received. (If CRC was enabled) After the CRC is sampled, the RCVEN bit will be cleared to reinitialize the receiver. At this point the entire process may repeat to receive another message. BIT MODE RECEIVE OPERATION (SDLC etc.) -------------------------------------- For SDLC family protocols the DEC MODE bit must be reset. This changes the CRC checking to CRC/CCITT and enables the "stuffed" "0" bits in the data stream to be stripped out, restoring the original data. The "0" bits were originally inserted to avoid confusion of data with FLAG or ABORT characters. These characters are detected by the DUP11 when the DEC MODE bit is not set. COMM IOP-DUP Page 1-12 DUP11 The reset DEC MODE bit also causes a different function to be assigned to the low byte of PACSR. This byte may be used as a secondary station address for protocols supporting this option. This is under the control of bit 12 of PACSR. After initialization and any necessary handshaking with the modem, the RCVEN bit is set. After this bit is set, the receiver searches the incoming data for FLAG characters. If the receiver is operating in the primary mode, all data subsequent to the last initial FLAG character is presented to the program. The RSOM bit is set with the reception of the initial data character and RXDONE is set when the data is in the RXDBUF. If the receiver is in the secondary address mode, the character immediately following the last initial FLAG is compared with the low byte of PACSR. If the character matches the contents of that byte, the character immediately following is taken as the start of the data field and TSOM is set. If the contents do not match, the receiver resumes looking for FLAG characters and TSOM is not set. When the start of the data field is detected, RXACT is set in RXCSR. The data continues to be assembled (with any "stuffed" zeros removed) and transferred to the RXDBUF with each transfer setting RXDONE. The program reads the data from RXDBUF (which resets RXDONE) with each assertion of RXDONE. This process continues until the detection of a FLAG character which signifies the end of the message. The detection of the FLAG will cause REOM and RXDONE to set. The contents of the RXDBUF is invalid when REOM is set. If CRC checking is enabled, the check will be valid only when REOM is set. The entire contents of the message between the FLAG characters is included in the CRC check. INTERRUPT OPERATION -------------------- The DUP11 can be operated in two modes; flag mode, and interrupt mode. In flag mode, the DUP11 does not interrupt the processor. The RXCSR and TXCSR must be interrogated to determine the state of the respective DONE bits and the modem control or status bits. The interrogation must occur often enough to ensure that characters are removed from, or written into, the respective DBUF without causing data late or overrun conditions. In the interrupt mode, the DUP11 interrupts the processor when either DONE bit is set and when the modem changes status. There are two discrete types of interrupt which generate different vector addresses. Receiver and data set interrupts generate vector adress XX0. Transmitter interrupts generate vector address XX4. The XX portion of the vector is switch selectable. Whether the DUP11 is in interrupt or flag mode is determined by bits 5 and 6 of RXCSR and bit 6 of TXCSR. These are the interrupt enable bits. Bit 5 of RXCSR controls data set interrupts. Bit 6 of RXCSR and TXCSR control receiver and transmitter interrupts respectively. When each of these bits are set, the corresponding interrupt is enabled. Receiver and transmitter interrupts are initiated by the RXDONE and TXDONE bits respectively. If a DONE bit is set by the DUP11, and the corresponding interrupt is enabled, an interrupt is gated to the UNIBUS. In the 2020 the DUP11 is operated in the flag mode for data communications. The servicing of the DUP11 registers is done by the KMC11 which relieves the KS10 CPU of the overhead. In diagnostics for the DUP11 on the KS10 the DUP11 is operated in the interrupt mode. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From jg at jordi.guillaumes.name Tue May 28 17:39:21 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Tue, 28 May 2013 23:39:21 +0200 Subject: [Simh] DUP on simh In-Reply-To: <51A4D32B.60800@ieee.org> References: <51A4D32B.60800@ieee.org> Message-ID: <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Congratulations (and thank-yous) for anyone involved in this new enhancement :) Of course, I could not resist the temptation of giving it a try. So I have cloned my TOPS-10 installation and have MONGENed it with DUP support. First problem: If I select DECNET support I get a lot of undefined symbols UNLESS I select to include also ANF-10 support. I have to supose this is intended. And second problem: BOOT>[1,5]newsys.exe [Loading from DSKC:NEWSYS.EXE[1,5]] BTES11 28-May-13 Why reload: new Date: Time: ?Stopcode EMA, type=STOP, on CPU0 at 28-May-113 23:34:59 CPU Status Block APRID = 470130,,010001 CONI APR, = 001060,,000070 CONI PI, = 000000,,000271 CONI PAG, = 000000,,060002 DATAI PAG, = 500100,,000004 Reload monitor [Dumping on DSKC:CRASH.EXE[1,4]] Boom! My lack of knowledge prevents me to investigate further by now :) Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From Mark at infocomm.com Tue May 28 17:47:37 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Tue, 28 May 2013 14:47:37 -0700 Subject: [Simh] DUP on simh In-Reply-To: <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> References: <51A4D32B.60800@ieee.org> <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157902@REDROOF2.alohasunset.com> On Tuesday, May 28, 2013 at 2:39 PM, Jordi Guillaumes i Pons wrote: > Congratulations (and thank-yous) for anyone involved in this new > enhancement :) This is a work in progress. It does not yet work reliably in the basic PDP11 to PDP11 case. I'm still debugging this. > Of course, I could not resist the temptation of giving it a try. So I have cloned > my TOPS-10 installation and have MONGENed it with DUP support. > > First problem: If I select DECNET support I get a lot of undefined symbols > UNLESS I select to include also ANF-10 support. I have to supose this is > intended. I have no idea if a bare DUP11 was ever supported in TOPS10. The KMC/DUP combination devices worked together (the KMC controlled the DUP). We haven't gotten that far yet. Rob Jarratt has been working on the KMC and his work hasn't stabilized yet either. I'll let you know when things are in better shape. - Mark From b4 at gewt.net Tue May 28 19:12:07 2013 From: b4 at gewt.net (Cory Smelosky) Date: Tue, 28 May 2013 23:12:07 -0000 Subject: [Simh] DUP on simh References: <51A4D32B.60800@ieee.org> <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Message-ID: On Tue, 28 May 2013, Jordi Guillaumes i Pons wrote: > > > Congratulations (and thank-yous) for anyone involved in this new enhancement :) > > Of course, I could not resist the temptation of giving it a try. So I have cloned my TOPS-10 installation and have MONGENed it with DUP support. > > First problem: If I select DECNET support I get a lot of undefined symbols UNLESS I select to include also ANF-10 support. I have to supose this is intended. DECnet front end. Don't need the ANF-10 > > And second problem: > > BOOT>[1,5]newsys.exe > [Loading from DSKC:NEWSYS.EXE[1,5]] > > BTES11 28-May-13 > Why reload: new > Date: > Time: > > ?Stopcode EMA, type=STOP, on CPU0 at 28-May-113 23:34:59 > > > CPU Status Block > > APRID = 470130,,010001 > CONI APR, = 001060,,000070 > CONI PI, = 000000,,000271 > CONI PAG, = 000000,,060002 > DATAI PAG, = 500100,,000004 > Reload monitor > [Dumping on DSKC:CRASH.EXE[1,4]] > > Boom! My lack of knowledge prevents me to investigate further by now :) > Install the 7.05 update. > > Jordi Guillaumes i Pons > jg at jordi.guillaumes.name > HECnet: BITXOV::JGUILLAUMES > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From Mark at infocomm.com Wed May 29 11:39:14 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 29 May 2013 08:39:14 -0700 Subject: [Simh] KDP Documentation In-Reply-To: <51A4D32B.60800@ieee.org> References: <51A4D32B.60800@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> Hi Tim, On Tuesday, May 28, 2013 at 8:54 AM, Timothe Litt wrote: > I knew I had some documentation for the KMC/DUP combination, though I > still haven't found the COMIOP/DUP manual (AA-5670A-TC) in my > collection, or on-line. It may be on the -11 or VAX microfiche, but > I've contributed my sets to CHM. Don't think they've been digitized. > > Anyhow, the following memo describes COM IOP-DUP at a high level, and > describes in some detail how the KMC controls the DUP. It may be useful > for your efforts. One note: "flag mode" as used here has nothing to do > with the FLAG character of bit-stuffing protocols. It's a synonym for > polled (v.s. interrupt-driven) IO. > > By the way, there also was COM IOP-DZ, which did similar things with the > DZ11. Thanks for this. I've got a couple of questions for you or anyone else: 1) The below document mentions the possibility of one or two DUPs related to a single KMC. What tells the KMC which DUP it is to exchange data with, and how does it know the DUP's bus address? 2) You had mentioned previously that the host OS doesn't interact with the DUP device except for a possible initial device probe testing for NXM, and then writing zeros to the registers. What would happen if the OS didn't find/see the DUP at all? 3) How many KMC/DUP devices would work on a given Unibus if there were no power limitations (i.e. how many devices could the OS software interact with)? 4) Was there software support for talking to a bare DUP without a related KMC in any PDP10 operating systems? 5) Was this KMC/DUP combination ever a supported device on PDP11 or VAX systems? Thanks. - Mark > COMMUNICATIONS IOP-DUP > > > > > COMMUNICATIONS IOP-DUP > Page 1-2 > > > INTRODUCTION > ------------ > > > > > The sychronous communications options on the 2020 are comprised of a > KMC11 and either one or two DUP11s. This > combination can also be referred to as COMM IOP-DUP. > > The DUP11 forms an interface between a synchronous modem and the > UNIBUS. Eight bit bytes of data are transferred to > the DUP over the UNIBUS and are serialized and formatted for transmission. > The format of the data stream is controlled by > registers in the DUP which are read and written by either the CPU or a local > IO Processor. (IOP) > > The 2020 utilizes the KMC11 as the local IOP for the DUP11. The KMC is a > microprogrammed auxilliary microprocessor > designed for communications functions. The microprogram in the KMC is > held in a writable control store memory (CRAM 16 > bits x 1K) which is loaded over the UNIBUS by the 2020. This allows changes > in protocols etc. to be nearly transparent > to the CPU. > > The KMC transfers data between 2020 memory and the DUP using DMA > and NPR transfers. The DUP11 is operated in flag > mode (interrupts disabled) and is interrogated by the KMC11 periodically to > determine if the character being transmitted > is done or if a character has been assembled by the receiver. This relieves > the CPU of the extensive interrupt handling > which would otherwise be necessary to maintain the synchronous data > stream. > > > > REFERENCES > ---------- > > > > 1. KMC11 Users Manual EK-KMC11-OP-001 > > 2. COMM IOP-DUP Programming Manual AA-5670A-TC > > 3. DSKMA Diagnostic Microfiche AH-E373A-DD > > 4. DSDUA Diagnostic Microfiche AH-E371A-DD > > 5. DUP11 Maintenance Manual EK-DUP11-MM-002 > > 6. KS10 Maintenance Guide EK-OKS10-MG-001 > > 7. Terminals and Communications Handbook > > > COMM IOP-DUP Page 1-3 > KMC11 > > > The functional operation of the KMC11 is totally dependent on the > microcode internal to the unit. Since this > microcode is in a writable control store, no attempt will be made to > present internal operations of the KMC11 in this > course. We will deal with the functional interface between the KMC11, > DUP11, and the UNIBUS. > > The KMC11 has 4 UNIBUS addressable registers. (REFER to Fig. 1) All > communications between the CPU and the KMC11 > are accomplished using these registers. The KMC11 views these as 8 byte > size registers.(BSEL 0-7, addresses 76XXX0-7) > They appear to the UNIBUS as 4, word or byte addressable, registers.(SEL 0, > 2, 4, and 6) > > Only the high byte of register SEL 0 (BSEL 1) has a fixed function. This is > the Maintenance Register. The remainder > of the UNIBUS register functions are controlled by the KMC11 microcode and > the CPU software. > > The Maintenance Register can be used to alter the KMC11 internal data > paths for loading the CRAM and for other > maintenance functions. > > For most maintenance functions, the RUN bit of the maintenance > Register will be cleared. This stops the > microprocessor clock which allows the CPU to manipulate the UNIBUS > registers without interference from the KMC11. > > Bit 10 of the maintenance register ,when set, causes the 10 low order bits > of SEL 4 to be used as an address for > CRAM. SEL 6 can then be used for either reading or writing the addressed > CRAM location. The read or write is controlled > by maintenance register bits 10 and 9 + 10 + 13 respectively. > > To access CRAM, the 2020 CPU will clear the RUN bit of the Maintenance > Register. It will then load the desired CRAM > address into bits 0 -> 9 of SEL 4. If the operation is to write CRAM, the CPU > will load SEL 6 with the new CRAM data and > write the Maintenance Register, setting bits 9, 10 and 13. This will cause the > KMC11 to write the data in SEL 6 to the > CRAM location specified by SEL 4 bits 0 -> 9. To read CRAM, the CPU will > write the Maintenance Register bit 10. This > will cause the data in the CRAM location specified by bits 0->9 of SEL 4 to be > transferred to SEL 6. The CPU will then > read SEL 6 to determine the contents of the CRAM location. > > The Maintenance Register can be used to single step through instructions > supplied by the CPU, read CRAM, and single > step through the microcode for diagnostic purposes. > > The KMC11 has its own internal memory (1k x 8 bits) which it uses for data > storage and computation. This memory can > not be used for instruction storage nor can the CRAM contents be modified > by the KMC11. > > > > COMM IOP-DUP Page 1-4 > KMC11 - UBA - MEMORY DATA TRANSFER > > > The KMC11 receives commands from the CPU through it's UNIBUS registers. > The microcode interprets the command and then > takes the proper actions to process the command. The KMC11 can also > send commands to the CPU by writing it's UNIBUS > registers and posting an interrupt to the UNIBUS. > > There are 3 commands which must occur before transmit and receive > operations can take place. > > > 1. INITIALIZATION; This command must be performed after loading > KMC11 microcode to initiate operation. > > > 2. A BASE IN command for each DUP11; This command informs the KMC > of the line number assignment and CSR base > address of each DUP11. > > > 3. A CONTROL IN command for each DUP11; This command sets up the > line parameters for each DUP11 and the polling > rate to be used in interrogating the DUP CSRs. > > > > The COMM IOP-DUP handles the modem handshaking and monitoring with > the exception of the RING and CARRIER lines. The COMM > IOP-DUP does all of the memory to transmitter and receiver to memory > data handling. The CPU informs the COMM IOP-DUP of > the areas in memory to be used for transmit and receive data. This is done > through BUFFER DESCRIPTOR LISTS for each > transmit and receive channel. > > Each buffer descriptor list points to the start of a series of 3 word (16 bit > word length) buffer descriptors in > contiguous memory locations. Each buffer descriptor contains; a starting > address for the buffer, a byte count, and > control fields for the starting and stopping of messages etc.. The buffers may > be scattered throughout main memory with > the descriptors pointing to them. > > The major requirement is that the buffer descriptor list be in a series of > continuous memory locations. Up to 2 > lists may be sent to the KMC11 for each transmit and receive line. The lists > are sent to the COMM IOP-DUP when the CPU > desires to transmit or receive messages. > > This is done with a BUFFER ADDRESS IN command. This command has the > starting address of the buffer descriptor list, > the line number the list applies to, and a bit controlling whether it is a > transmit or receive buffer. > > > NOTE > > The CPU will also have to set up the UBA pager for the buffer areas in > memory for address > translation from 18 bit UNIBUS to KS10 addressing. > > > > The KMC11 uses the buffer descriptor lists to set up it's DMA addressing > for each transmit and receive line. Once > the lists are in the KMC11, the actual data transfer operations are transparent > to the CPU. > > > NOTE > > All transfers initiated by the KMC11 over the UNIBUS are NPRs. The > only time the KMC11 > "talks" to the 2020 CPU is when the CPU writes the KMCs > registers, or when posting an > interrupt on the UNIBUS. > > > > COMM IOP-DUP Page 1-5 > KMC11 - UBA - MEMORY DATA TRANSFER > > > TRANSMIT > -------- > > > NOTE > > The following description is for DDCMP operation of the COMM IOP- > DUP. > > > > The CPU will compile the message to be sent in memory and transfer the > buffer descriptor list to the KMC11. > > The KMC11 receives the buffer descriptor list with the command to > transmit and retreives the first buffer descriptor > from memory. The KMC then does the required handshaking with the > modem via the RXCSR register of the DUP11. The KMC > initiates the message by setting the SEND bit in TXCSR of the DUP and > transferring a SYNC character and the TSOM bit to > the TXDBUF. > > As each character is transferred from the TXDBUF to the transmitter shift > register in the DUP, TXDONE will be set in > TXCSR. The KMC checks the TXCSR for TXDONE by periodically reading the > register. > > The rate at which the DUP11 registers are polled by the KMC is controlled > by one of the set up commands sent to the > KMC by the CPU at system initialization. > > When the KMC detects TXDONE, it will transfer another character to the > TXDBUF of the DUP. This will continue until 8 > SYNC characters have been transferred, when the KMC will reset the TSOM > bit. > > > NOTE > > The COMM IOP-DUP microcode in the KMC11 can send 8 sync > characters automatically in DDCMP > mode, depending on a control bit within the buffer descriptor. If > the control bit is not > set, the sync characters (if any) must be included with the message. > > > > At this point the KMC will begin transferring message data from 2020 > memory using NPRs. The transfer sequence is > similar to the NPR slow mode transfer used for the tape unit, but 36 bit mode > is not set. > > As each data word is received from the system, the KMC places it in it's > internal memory and waits for TXDONE to set. > When the KMC detects TXDONE on a polling cycle, it transfers an 8 bit > character to the DUP TXDBUF register using a byte > mode NPR. > > This process is repeated until the number of characters transferred is > equal to the byte count within the buffer > descriptor. Depending on the state of control bits in the buffer descriptor , > the KMC will either; start transmitting > data from a second buffer descriptor or buffer descriptor list and interrupt > the CPU , or terminate the message. > > When the last character of the message is transferred to the DUP, the > KMC will set the TEOM bit in the TXCSR. This > causes the accumulated CRC to be transmitted immediately after the last > character. > > A second message may start immediately after the first, using another > buffer descriptor or buffer descriptor list. > Messages may be strung together this way until no buffer descriptor list is > pending in the KMC. Alternately, a message > may be distributed among several buffer descriptors or descriptor lists, > terminating only when the bit, in the buffer > descriptor, controlling the setting of the TEOM bit, is set. > > COMM IOP-DUP Page 1-6 > KMC11 - UBA - MEMORY DATA TRANSFER > > > RECEIVE > ------- > > > NOTE > > The following discussion assumes that the COMM IOP-DUP has been > initialized and that DDCMP > is the protocol. > > > > The COMM IOP-DUP receive operation is initiated when the CPU assigns a > buffer descriptor list or lists to a receive > line. The buffer descriptor list tells the KMC11 where in memory to place > received data. If data is received by the > DUP11 and no buffer descriptor list is assigned, the COMM IOP-DUP will post > an error to the CPU via an interrupt. > > When the first non-sync character is received and in the RXDBUF, the > DUP11 sets RXDONE. This is detected by the > KMC11 on the next polling cycle and the character is transferred to the KMC > with a byte mode NPR. > > If the first character following the leading sync characters is not an SOH, > ENQ or DLE character the associated DUP11 > is resynchronized. In this case no interrupt is sent to the CPU. > > The KMC will assemble the characters into 16 bit words for transfer to > main memory. As each word is assembled, the > KMC will issue an NPR transfer, through the UBA, to main memory. The > transfer sequence resembles the NPR slow mode > transfers used for tape system data transfer with 36 bit mode disabled. > > The first six bytes in DDCMP protocol are the HEADER. This is treated as a > discrete message by the hardware and CRC > is done on these six bytes. If a header CRC error occurs, the KMC aborts > reception, posts an error interrupt to the CPU, > and resumes searching for sync characters. > > The HEADER is analyzed by the KMC11 for the BYTE COUNT and the > DDCMP quick sync bit. The byte count allows the KMC > to discern the message CRC characters from the last data character in the > message. If the quick sync bit is set, the KMC > will place the applicable DUP11 in sync search mode immediately following > the end of the message. If the quick sync bit > is not set, the KMC11 assumes the next message is either abutted to the > current message or is preceded by at least 8 sync > characters. > > The KMC will continue transferring data from the DUP at each assertion of > RXDONE, assembling 16 bit words, and > transferring the words to memory until the number of bytes received equals > the byte count in the header. > > The KMC11 will not post a completion interrupt to the CPU until the entire > message has been received unless the > message is larger than the currently assigned message buffer. If the > message is larger than the current buffer, the KMC > will post an interrupt to the CPU and continue transferring data to the next > buffer defined in the buffer descriptor list. > > When the last character of the message has been received, the KMC will > check the CRC and do one of three things: > > 1. If CRC was bad, the KMC will post an error interrupt to the CPU and > immediately enter sync search mode. > > 2. If CRC was good and the quick sync bit was set in the header, the KMC > will start looking for another message > preceded by less than 8 sync characters. > > 3. If CRC was good and the quick sync bit wasn't set, the KMC will examine > the next character after the CRC and, if > it is a start of header (SOH), continue reception of the next message, > placing the data in the next buffer. > > > COMM IOP-DUP Page 1-7 > KMC11 - UBA - MEMORY DATA TRANSFER > > > There are two output commands issued by the KMC11 to the CPU. The > first is a CONTROL OUT command and is used in > posting error conditions to the CPU. The second is the BUFFER ADDRESS > OUT command used to indicate that that a buffer > assigned by a buffer descriptor has been filled or its' contents transmitted. > The buffer address out command is also used > when a complete message has been received, whether or not it has filled a > buffer. In any case, the KMC will shift its' > memory NPR operations to the next buffer in the buffer descriptor list or > to the next buffer descriptor list as > applicable. > > > COMM IOP-DUP Page 1-8 > DUP11 > > > INTRODUCTION > ------------ > > > The DUP11, together with the KMC11, forms a synchronous > communications subsystem for the 2020. High speed > synchronous communications capability allows the 2020 to be used in > computer networking applications such as DECNET. This > type of application may be a major factor in a buyer's decision on which > computer system he will purchase. > > BASIC BLOCK FUNCTIONS > --------------------- > > The DUP11 basic block can be broken down into three major areas; > > 1. THE UNIBUS INTERFACE comprised of the UNIBUS tranceivers, the > interrupt control logic, the address select logic, > the reset logic, and the UNIBUS multiplexer. > > 2. THE REGISTERS AND CONTROL LOGIC comprised of the five registers > and part of the TX control and RX control logic. > > 3. THE MODEM INTERFACE comprised of the remainder of the TX control > and RX control logic and the clock logic. > > UNIBUS INTERFACE > ---------------- > > > This section of the DUP11 is responsible for getting data into and out of > the unit to the UNIBUS. The address select > logic decodes the UNIBUS address lines and determines if the address on the > lines matches the switch settings on the DUP11 > and what type of data cycle is required. > > The interrupt control logic will issue a BR when conditions internal to the > DUP11 require processor intervention. > The interrupt logic can be enabled or disabled under software control. > > The reset logic initializes the DUP11 when a UNIBUS initialize signal occurs. > The reset logic will also initialize > the DUP11 under software control when TXCSR bit 8 is set. > > The UNIBUS tranceivers and multiplexer receive and transmit data > between the UNIBUS and the DUP11 registers under > control of the address select logic. > > DUP11 REGISTERS > --------------- > > There are 5 registers in the DUP11 which are used to control it's operation > and communicate with the UNIBUS. > > 1. The RXCSR register is used to control the operation of the receiver > section of the DUP11 and to interface with > the modem. The register is R/W and is word and byte addressable. > > 2. The RXDBUF is a read only register which holds the received data in the > low byte and status information in the > high byte. The RXDBUF shares the same address with PACSR and is > word addressable. > > 3. The PACSR is a write only register which controls the overall mode of > the DUP11. This register contains the DEC > mode bit, the bit which determines whether CRC is to be used or not, > the secondary address mode bit, and either > the secondary address or the SYNC character in the low byte. The > PACSR and the RXDBUF share the same address and > are word addressable only. > > COMM IOP-DUP Page 1-9 > DUP11 > > > 4. The TXCSR register is used to control the operation of the transmitter > section of the DUP11 and to control > maintenance functions. The register is read/write and word and byte > addressable. > > 5. The TXDBUF register contains the remainder of the control and status > bits for the transmitter and the low byte > holds the data to be transmitted. The register is word and byte > addressable and is a read/write register. > > TX CONTROL LOGIC > ---------------- > > The transmit control logic is responsible for: > > 1. Serializing data to be transmitted and transferring it to the modem. > > 2. Transmission of FLAG and ABORT sequences in bit oriented protocols. > (DEC MODE reset) > > 3. Bit stuffing when in bit oriented protocols. > > 4. Signaling when the character currently being transmitted is done by > setting TXDONE in TXCSR. > > 5. Computing CRC in either CRC-16 or CRC/CCITT format on transmitted > data. > > RX CONTROL LOGIC > ---------------- > > The receiver control logic is responsible for: > LE;Synchronizing the receiver logic with the received signal. > > 1. Assembling the received serial data in the receiver shift register and > transferring it to the RXDBUF. > > 2. Signaling when the latest assembled character is available in the > RXDBUF by asserting RXDONE. > > 3. "Stripping" extra leading SYNC characters after synchronization when in > DEC mode. LE;Deleting "stuffed" "0" bits > from the data stream when not in DEC mode. > > 4. Detecting FLAG and ABORT sequences when not in DEC mode. > > 5. Checking received CRC characters against computed CRC characters in > CRC-16 or CRC/CCITT formats. > > FUNCTIONAL DESCRIPTION > ---------------------- > > > The transmit operation of the DUP11 is somewhat dependent on whether > a bit oriented protocol (SDLC type protocols) or > a byte oriented protocol (DDCMP etc.) is being used. > > BYTE ORIENTED OPERATION (DDCMP and BISYNC) > ------------------------------------------ > > > For byte mode operation the DEC mode bit in PACSR must be set. This will > cause the CRC circuits to use the CRC/16 > format to check and generate CRC. This bit also controls whether "0" bits > are "stuffed" into or stripped from a data > stream containing more than 5 consecutive "1" bits. When the DEC mode bit > is set, bit stuffing is not done. > > COMM IOP-DUP Page 1-10 > DUP11 > > > The CRC PAR INH bit in PACSR is used to enable or disable CRC generation > or error detection. This bit will usually > be set on BISYNC protocols and reset for DDCMP. > > All "handshaking" with the modem must be completed prior to the start > of transmission. This is done through the > RXCSR register. The "handshaking" is not automatic and must be done by the > program. > > The insertion of Sync characters is also a program function. The DUP11 > has no provision for automatically > transmitting sync characters. > > Transmission begins when the program sets the SEND bit in TXCSR and > loads a sync character into the TXDBUF along with > the Transmit Start Of Message bit. All sync characters must be loaded by the > program and the TSOM bit held asserted until > the start of the last sync character. As each character is sent out, the > TXDONE bit is set in TXCSR. The program will > get another sync character, load it into TXDBUF and repeat until the proper > number of sync characters have been sent. > After the start of the last sync character the program will clear TSOM. At the > next assertion of TXDONE the first data > character will be loaded into TXDBUF and the CRC circuit will start to > compute the CRC code for the data portion of the > message. > > > NOTE > > The CRC calculation can be inhibited by bit 09 of PACSR. This will > usually be the case for > BISYNC type protocols. > > > > The program will continue to load characters into the TXDBUF, at each > transition of TXDONE, until the end of the > message. When the last character is loaded, the TEOM bit will also be set by > the program. This will cause the CRC check > character to be transmitted immediately following the last data character. (If > the CRC is enabled) > > BIT ORIENTED OPERATION (SDLC etc.) > ---------------------------------- > > For operation in SDLC or other bit oriented protocols the DEC MODE bit in > PACSR must be reset. This allows bit > stuffing (The insertion of a "0" bit after each 5 consecutive "1" bits in a data > stream of more than 5 consecutive "1" > bits) to prevent confusing data with FLAG and ABORT sequences. > > The DEC MODE bit being reset also alters the CRC computation so that the > CRC conforms to CRC/CCITT format. Some > protocols may compute the CRC differently and if one of those is in use the > CRC will be disabled using bit 09 of PARCSR. > If CRC is disabled the program must compute any required CRC for the > protocol in use. > > > NOTE > > The following discussion assumes that all required "handshaking" > with the modem has been > completed and the DUP11 has been initialized. > > > > To start transmission, the SEND bit must be set in TXCSR and the TSOM bit > in TXDBUF. This will cause an initial FLAG > character to be transmitted. FLAGs will continue to be transmitted until the > TSOM bit is reset. The transmission of FLAG > characters in this mode is automatic and the characters do not have to be > loaded into the TXDBUF by the processor. When > the TSOM bit is reset, the TXDONE bit will be asserted at the conclusion of > the character in transmission. > > COMM IOP-DUP Page 1-11 > DUP11 > > > When the program "sees" TXDONE, it will start transferring data to the > TXDBUF. At each assertion of TXDONE, another > character of data will be loaded. The CRC computation (if enabled) starts > with the transfer of the first data to TXDBUF. > The transmitter also enters the "transparent" state (bit stuffing is enabled) > when the transmitter starts sending data. > > At the conclusion of the message the program sets the TEOM bit in > TXDBUF and, at the end of the character being > serialized, (if CRC is enabled) the CRC character is transmitted. At the > conclusion of the CRC character a FLAG character > is automatically transmitted. > > The program has three options at this point: SEND may be cleared, which > allows the FLAG character to be completed > and after a delay of 1 1/2 bit times the transmitter enters the IDLE state. > TEOM may be held set, which will cause > continuous FLAG characters to be transmitted. TEOM may be cleared and a > second data message started without setting TSOM. > > The receiver section operates differently for byte oriented and bit > oriented protocols and the two modes are > discussed separately in the following section. > > BYTE ORIENTED RECEIVER (DDCMP, BISYNC etc.) > ------------------------------------------- > > > For BYTE mode operation, the DEC MODE bit and the SYNC character to be > used must be loaded into the PACSR prior to > enabling the receiver. The DEC MODE bit causes the low byte of PACSR to > be recognized as a SYNC character, and the CRC > circuitry of both the receiver and transmitter to use CRC-16 for generating > and checking CRC. > > The STRIP SYNC bit of RXCSR may also be set, which allows SYNC > characters occuring after receiver synchronization to > be automatically deleted. Synchronization is considered complete when 2 > succesive characters which match the low byte of > PACSR have been recognized. The STRIP SYNC bit causes any other leading > SYNC characters to be ignored. > > After the initialization and any needed modem handshaking has been > done, the RCVEN bit in RXCSR may be set. This > enables the receiver to search the incoming signals until 2 successive SYNC > characters are detected. All characters > following the detection of the 2 successive SYNC characters are interpreted > as data. (Unless the STRIP SYNC bit is set, > when it is the detection of the first non-SYNC character that will cause all > following characters to be interpreted as > data.) When this has occured, the RXACT bit will be asserted and the RXDONE > bit set. (Also this will disable the STRIP > SYNC logic until the receiver logic is reinitialized.) > > All data following the SYNC characters is included in the CRC calculation. > For some protocols in the BISYNC family > the CRC logic must be disabled due to possible control characters in the data > field. > > Once RXDONE is set the program will read the assembled character in the > RXBUF, reseting RXDONE. This process will > repeat until the expected number of characters has been received. The > program will then sample the CRC PAR ERR bit to > determine if there was an error in the data received. (If CRC was enabled) > After the CRC is sampled, the RCVEN bit will > be cleared to reinitialize the receiver. > > At this point the entire process may repeat to receive another message. > > BIT MODE RECEIVE OPERATION (SDLC etc.) > -------------------------------------- > > > For SDLC family protocols the DEC MODE bit must be reset. This changes > the CRC checking to CRC/CCITT and enables the > "stuffed" "0" bits in the data stream to be stripped out, restoring the > original data. The "0" bits were originally > inserted to avoid confusion of data with FLAG or ABORT characters. These > characters are detected by the DUP11 when the > DEC MODE bit is not set. > > COMM IOP-DUP Page 1-12 > DUP11 > > > The reset DEC MODE bit also causes a different function to be assigned to > the low byte of PACSR. This byte may be > used as a secondary station address for protocols supporting this option. This > is under the control of bit 12 of PACSR. > > After initialization and any necessary handshaking with the modem, the > RCVEN bit is set. After this bit is set, the > receiver searches the incoming data for FLAG characters. If the receiver is > operating in the primary mode, all data > subsequent to the last initial FLAG character is presented to the program. > The RSOM bit is set with the reception of the > initial data character and RXDONE is set when the data is in the RXDBUF. > > If the receiver is in the secondary address mode, the character > immediately following the last initial FLAG is > compared with the low byte of PACSR. If the character matches the > contents of that byte, the character immediately > following is taken as the start of the data field and TSOM is set. If the > contents do not match, the receiver resumes > looking for FLAG characters and TSOM is not set. > > When the start of the data field is detected, RXACT is set in RXCSR. The > data continues to be assembled (with any > "stuffed" zeros removed) and transferred to the RXDBUF with each transfer > setting RXDONE. The program reads the data from > RXDBUF (which resets RXDONE) with each assertion of RXDONE. > > This process continues until the detection of a FLAG character which > signifies the end of the message. The detection > of the FLAG will cause REOM and RXDONE to set. The contents of the > RXDBUF is invalid when REOM is set. > > If CRC checking is enabled, the check will be valid only when REOM is set. > The entire contents of the message > between the FLAG characters is included in the CRC check. > > INTERRUPT OPERATION > -------------------- > > The DUP11 can be operated in two modes; flag mode, and interrupt > mode. > > In flag mode, the DUP11 does not interrupt the processor. The RXCSR and > TXCSR must be interrogated to determine the > state of the respective DONE bits and the modem control or status bits. > The interrogation must occur often enough to > ensure that characters are removed from, or written into, the respective > DBUF without causing data late or overrun > conditions. > > In the interrupt mode, the DUP11 interrupts the processor when either > DONE bit is set and when the modem changes > status. > > There are two discrete types of interrupt which generate different > vector addresses. Receiver and data set > interrupts generate vector adress XX0. Transmitter interrupts generate > vector address XX4. The XX portion of the vector > is switch selectable. > > Whether the DUP11 is in interrupt or flag mode is determined by bits 5 > and 6 of RXCSR and bit 6 of TXCSR. These are > the interrupt enable bits. Bit 5 of RXCSR controls data set interrupts. Bit 6 > of RXCSR and TXCSR control receiver and > transmitter interrupts respectively. When each of these bits are set, the > corresponding interrupt is enabled. > > Receiver and transmitter interrupts are initiated by the RXDONE and > TXDONE bits respectively. If a DONE bit is set > by the DUP11, and the corresponding interrupt is enabled, an interrupt is > gated to the UNIBUS. > > In the 2020 the DUP11 is operated in the flag mode for data > communications. The servicing of the DUP11 registers is > done by the KMC11 which relieves the KS10 CPU of the overhead. In > diagnostics for the DUP11 on the KS10 the DUP11 is > operated in the interrupt mode. > > > > > -- > This communication may not represent my employer's views, > if any, on the matters discussed. > From litt at ieee.org Wed May 29 12:37:29 2013 From: litt at ieee.org (Timothe Litt) Date: Wed, 29 May 2013 12:37:29 -0400 Subject: [Simh] KDP Documentation In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> References: <51A4D32B.60800@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> Message-ID: <51A62EC9.60404@ieee.org> > I've got a couple of questions for you or anyone else: > 1) The below document mentions the possibility of one or two DUPs > related to a single KMC. What tells the KMC which DUP it is to > exchange data with, and how does it know the DUP's bus address? The KMC is passed the DUP's address by the OS in a base in command. (It must be in the IO page, so the high address bits don't need to be sent.) ; BASEIN: BSEL2/ *400+3 ; BSEL6/ &017770 The OS knows - it probes the unibus or has the first DUP CSR hard-coded (varies withOS). Then when other commands are sent to the KMC, they include the line number. This is used to find the right DUP. The KMC starts polling the DUP when Control-IN sets ENABLE. > 2) You had mentioned previously that the host OS doesn't interact with > the DUP device except for a possible initial device probe testing for > NXM, and then writing zeros to the registers. What would happen if the > OS didn't find/see the DUP at all? The OS checks for the DUP, and disables the line if it's not present (NXMs). TOPS-20 writes zeros to the registers for some reason - probably paranoia. I have a vague memory that modem status may be looked-at as well, but haven't tracked it down. > 3) How many KMC/DUP devices would work on a given Unibus if there were > no power limitations (i.e. how many devices could the OS software > interact with)? TOPS-20 is hard-coded at 1 KDP with 1 or 2 lines. Expanding the number of lines would be easy; another KDP would be hard. TOPS-10 is coded for more, but the configuration utility has limited it. This would be a trivial patch - note that TOPS-10 monitors are compiled for each system. The limits would be the line number field in the KDP commands, and Unibus mapping resources - each DUP takes at least 1 page - depends on the configured max message size. UBA's are limited to 64 pages (each, but the KDP is known to be on UBA3). But every DMA device uses some. TOPS-10 also supports the DMR (up to 8) - which would be a better way to expand. With two lines, typically a -10 or -20 would use one for DECnet - talking to a router. The other for another protocol; ANF-10, IBM comm. Both happily used gateways to other networks hosted on VAX or 11s, or KLs. Though we tried to use cheap 16/32-bit machines for the grunt work of pushing bits around. > 4) Was there software support for talking to a bare DUP without a > related KMC in any PDP10 operating systems? > Not any DEC OS. Can't speak for ITS, but I doubt it. > 5) Was this KMC/DUP combination ever a supported device on PDP11 or > VAX systems? Thanks. - Mark I don't have a reference handy, but I think it was supported at least on VAX and 11M. They could have a mixture of stand-alone DUPs and DUPs controlled by KMCs. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Jason.Armistead at otis.com Thu May 30 14:58:54 2013 From: Jason.Armistead at otis.com (Armistead, Jason) Date: Thu, 30 May 2013 18:58:54 +0000 Subject: [Simh] What does "DUP" stand for ? Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu May 30 15:12:34 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 30 May 2013 12:12:34 -0700 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> The recent discussions about KMC11 and DUP11 are about specific devices which existed in the past and were used to provide link layer connectivity for host communicating via DECnet. This has absolutely nothing to do with the SET HOST /DUP. From what I recall, the /DUP in this usage stands/stood for "Diagnostic Utility Protocol)". This is the sum totol of my knowledge on this subject though. The VMS Help says: SET HOST /DUP Connects your terminal to a storage controller through the appropriate bus for that controller. The /SERVER and /TASK qualifiers are required. For use only with storage controllers. Requires the DIAGNOSE privilege. Format SET HOST/DUP/SERVER=server-name /TASK=task-name node-name Additional information available: Parameter Qualifiers /LOG /SERVER /TASK Example From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason Sent: Thursday, May 30, 2013 11:59 AM To: simh at trailing-edge.com Subject: [Simh] What does "DUP" stand for ? There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Thu May 30 15:14:07 2013 From: bqt at softjar.se (Johnny Billquist) Date: Thu, 30 May 2013 21:14:07 +0200 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <51A7A4FF.8050704@softjar.se> On 2013-05-30 20:58, Armistead, Jason wrote: > There?s been a lot of discussion regarding KMC11 and DUP lately. > Can someone remind me what the acronym DUP stands for ? I?ve done a SET > HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but > that was so long ago and I?m a bit rusty. That is a different DUP. :-) Your DUP stands for Diagnostics Utility Protocol, or something like that. The DUP-11 is a synchronous serial interface. A piece of hardware. Johnny From tshoppa at wmata.com Thu May 30 15:18:14 2013 From: tshoppa at wmata.com (Shoppa, Tim) Date: Thu, 30 May 2013 19:18:14 +0000 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <303A17BD5F8FA34DA45EEC245271AC0B74397247@JGEX2K10MBX2.wmata.local> In SET HOST/DUP/DSSI, DUP expands to "Device Utility Program". I think the is the same expansion and in the same spirit as for RT-11 DUP although of course RT-11 DUP worked with a many different generations of devices older than DSSI. In the communications context, DUP-11 refers to the DUP-11 synchronous interface board. From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason Sent: Thursday, May 30, 2013 2:59 PM To: simh at trailing-edge.com Subject: [Simh] What does "DUP" stand for ? There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From litt at ieee.org Thu May 30 15:21:13 2013 From: litt at ieee.org (Timothe Litt) Date: Thu, 30 May 2013 15:21:13 -0400 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> Message-ID: <51A7A6A9.7020606@ieee.org> DUP-11 is a comm device - sync line controller. The DUP protocol is part of the packet-based mass storage protocols used by CI (e.g. HSC), DSSI, and UQSSP controllers. Yes, it's Diagnostic Utility Protocol. It's used for configuring, monitoring and running diagnostics on the embedded microcontroller (often a PDP-11 or VAX) that runs a storage controller. This communication may not represent my employer's views, if any, on the matters discussed. On 30-May-13 15:12, Mark Pizzolato - Info Comm wrote: > > The recent discussions about KMC11 and DUP11 are about specific > devices which existed in the past and were used to provide link layer > connectivity for host communicating via DECnet. > > This has absolutely nothing to do with the SET HOST /DUP. From what I > recall, the /DUP in this usage stands/stood for "Diagnostic Utility > Protocol)". This is the sum totol of my knowledge on this subject > though. The VMS Help says: > > SET > > HOST > > /DUP > > Connects your terminal to a storage controller through the > > appropriate bus for that controller. The /SERVER and /TASK > > qualifiers are required. > > For use only with storage controllers. Requires the DIAGNOSE > > privilege. > > Format > > SET HOST/DUP/SERVER=server-name > > /TASK=task-name node-name > > Additional information available: > > Parameter Qualifiers > > /LOG /SERVER /TASK > > Example > > *From:*simh-bounces at trailing-edge.com > [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *Armistead, Jason > *Sent:* Thursday, May 30, 2013 11:59 AM > *To:* simh at trailing-edge.com > *Subject:* [Simh] What does "DUP" stand for ? > > There's been a lot of discussion regarding KMC11 and DUP lately. > > Can someone remind me what the acronym DUP stands for ? I've done a > SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, > but that was so long ago and I'm a bit rusty. > > Cheers > > Jason > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From dave_list_addr at verizon.net Thu May 30 18:48:29 2013 From: dave_list_addr at verizon.net (dave porter) Date: Thu, 30 May 2013 18:48:29 -0400 Subject: [Simh] Simh Digest, Vol 113, Issue 24 In-Reply-To: References: Message-ID: <24E85722F40B4AD3BCFF2970701E59BC@street> > What does DUP stand for? Mostly it stands for the fact that all the good 2-character communication device names were already taken. In particular we already had a DU11 and a DP11 ... I think the DUP11 might have been a replacement for the DP11 (not in any 'compatible' sense), but since my 1976 Peripherals Handbook has gone missing, I can't be too sure. dave From aek at bitsavers.org Thu May 30 19:02:47 2013 From: aek at bitsavers.org (Al Kossow) Date: Thu, 30 May 2013 16:02:47 -0700 Subject: [Simh] Simh Digest, Vol 113, Issue 24 In-Reply-To: <24E85722F40B4AD3BCFF2970701E59BC@street> References: <24E85722F40B4AD3BCFF2970701E59BC@street> Message-ID: <51A7DA97.1010804@bitsavers.org> On 5/30/13 3:48 PM, dave porter wrote: > my 1976 Peripherals Handbook has gone missing 72, 73 and 76 are on line under http://bitsavers.org/pdf/dec/pdp11/handbooks From Mark at infocomm.com Fri May 31 12:38:57 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 31 May 2013 09:38:57 -0700 Subject: [Simh] card reader and running commands References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E7315795F@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:25 PM, Mark Pizzolato wrote: > On Monday, May 27, 2013 at 1:12 PM, Jordi wrote: > > El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm > > va escriure: > > > > > The Remote Console Facility allows a TELNET Connection to a user > > designated port so that some out of band commands can be entered to > > manipulate and/or adjust a running simulator. The commands which > > enable and control this capability are SET REMOTE TELNET=port, SET > > REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW > REMOTE. > > > > Hi Mark, > > > > The remote console addition is really useful! (It would justify > > upgrading simh to 4.0 by itself, in my opinion). I, however, have a > > suggestion: could you add a command to disconnect the telnet session? > > Right now the only way is to break into TELNET command mode and CLOSE > the connection there... > > Hmmm... You have to do the same thing to disconnect from any console > session.... This seems easy enough... Well, after further thought. I've changed the remote console to exit the current remote console session when an EOF character is received (i.e. either ^D or ^Z). - Mark From robert.jarratt at ntlworld.com Tue May 7 18:33:36 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Tue, 7 May 2013 23:33:36 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? Message-ID: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Can anyone point me at the right place to look at TOPS-20 driver code for the KMC11? I can see that it is trying to get the Microprocessor to do something and read back some values, but I don't know what values it wants to get and so it reports: ******************** *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 *KMC11 BROKEN *JOB: 0, USER: OPERATOR *ADDITIONAL DATA: 3760540 ******************** ******************** *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 *KMC11 LOAD FAILED *JOB: 0, USER: OPERATOR ******************** Thanks Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From simh at alderson.users.panix.com Tue May 7 20:01:46 2013 From: simh at alderson.users.panix.com (Rich Alderson) Date: Tue, 7 May 2013 20:01:46 -0400 (EDT) Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> (robert.jarratt@ntlworld.com) References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Message-ID: <20130508000146.A1B69242BE@panix5.panix.com> > From: "Robert Jarratt" > Date: Tue, 7 May 2013 23:33:36 +0100 > Can anyone point me at the right place to look at TOPS-20 driver code for > the KMC11? I can see that it is trying to get the Microprocessor to do > something and read back some values, but I don't know what values it wants > to get and so it reports: Hi, Rob, http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html You want the file KDPSRV.MAC in that directory. Rich From litt at ieee.org Tue May 7 20:07:40 2013 From: litt at ieee.org (Timothe Litt) Date: Tue, 07 May 2013 20:07:40 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> Message-ID: <5189974C.3080508@ieee.org> This is a failure loading the KMC microcode. You have to store the bits you get, and allow them to be read back. This communication may not represent my employer's views, if any, on the matters discussed. On 07-May-13 18:33, Robert Jarratt wrote: > > Can anyone point me at the right place to look at TOPS-20 driver code > for the KMC11? I can see that it is trying to get the Microprocessor > to do something and read back some values, but I don't know what > values it wants to get and so it reports: > > ******************** > > *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 > > *KMC11 BROKEN > > *JOB: 0, USER: OPERATOR > > *ADDITIONAL DATA: 3760540 > > ******************** > > ******************** > > *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 > > *KMC11 LOAD FAILED > > *JOB: 0, USER: OPERATOR > > ******************** > > Thanks > > Rob > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Wed May 8 14:10:29 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Wed, 8 May 2013 19:10:29 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? Message-ID: <06ae01ce4c17$5435bdd0$fca13970$@ntlworld.com> Thanks to all those who responded, I now have the info I need. Regards Rob From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] Sent: 07 May 2013 23:34 To: hecnet at update.uu.se; simh at trailing-edge.com Subject: TOPS-20 Source with KMC11 Driver Code? Can anyone point me at the right place to look at TOPS-20 driver code for the KMC11? I can see that it is trying to get the Microprocessor to do something and read back some values, but I don't know what values it wants to get and so it reports: ******************** *BUGINF "KMCBRK" AT 7-MAY-2013 23:27:03 *KMC11 BROKEN *JOB: 0, USER: OPERATOR *ADDITIONAL DATA: 3760540 ******************** ******************** *BUGINF "KMCLOD" AT 7-MAY-2013 23:27:03 *KMC11 LOAD FAILED *JOB: 0, USER: OPERATOR ******************** Thanks Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.jarratt at ntlworld.com Wed May 8 17:29:53 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Wed, 8 May 2013 22:29:53 +0100 Subject: [Simh] TOPS20 4.1 DECnet Progress Message-ID: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Making progress: $OPR OPR>ENTER NCP NCP>SHOW STATUS KNOWN LINES NCP> 22:25:11 NCP request # 2 [SHOW STATUS KNOWN LINES] Status as of 8-May-2013 22:25:12 Line ID State Adjacent Node KDP_0_0 On KDP_0_1 On Function completed successfully NCP> J Regards Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri May 10 02:28:07 2013 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 10 May 2013 06:28:07 -0000 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Message-ID: On Wed, 8 May 2013, Robert Jarratt wrote: > > Making progress: > >   > > $OPR > > OPR>ENTER NCP > > NCP>SHOW STATUS KNOWN LINES > > NCP> > > 22:25:11          NCP request # 2 [SHOW STATUS KNOWN LINES] > >   > >         Status as of 8-May-2013 22:25:12 > >   > >         Line ID         State           Adjacent Node > >   > >         KDP_0_0         On > >         KDP_0_1         On > >           Function completed successfully > > NCP> > >   > > J > >   > > Regards > >   > > Rob > > > I wonder if it would be possible to apply what you've done with TOPS-20 to TOPS-10. -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From robert.jarratt at ntlworld.com Fri May 10 13:25:39 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Fri, 10 May 2013 18:25:39 +0100 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress In-Reply-To: References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> Message-ID: <082101ce4da3$65a76400$30f62c00$@ntlworld.com> > -----Original Message----- > From: Cory Smelosky [mailto:b4 at gewt.net] > Sent: 10 May 2013 07:28 > To: Robert Jarratt > Cc: simh; hecnet > Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress > > On Wed, 8 May 2013, Robert Jarratt wrote: > > > > > Making progress: > > > > > > > > $OPR > > > > OPR>ENTER NCP > > > > NCP>SHOW STATUS KNOWN LINES > > > > NCP> > > > > 22:25:11          NCP request # 2 [SHOW STATUS KNOWN LINES] > > > > > > > >         Status as of 8-May-2013 22:25:12 > > > > > > > >         Line ID         State           Adjacent Node > > > > > > > >         KDP_0_0         On > > > >         KDP_0_1         On > > > >           Function completed successfully > > > > NCP> > > > > > > > > J > > > > > > > > Regards > > > > > > > > Rob > > > > > > > > I wonder if it would be possible to apply what you've done with TOPS-20 to > TOPS-10. > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to install DECnet on TOPS-10 have not gone well so far though, it fails to link after MONGEN. Regards Rob From b4 at gewt.net Fri May 10 13:29:00 2013 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 10 May 2013 17:29:00 -0000 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> <082101ce4da3$65a76400$30f62c00$@ntlworld.com> Message-ID: On Fri, 10 May 2013, Robert Jarratt wrote: > > > >> -----Original Message----- >> From: Cory Smelosky [mailto:b4 at gewt.net] >> Sent: 10 May 2013 07:28 >> To: Robert Jarratt >> Cc: simh; hecnet >> Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress >> >> On Wed, 8 May 2013, Robert Jarratt wrote: >> >>> >>> Making progress: >>> >>> >>> >>> $OPR >>> >>> OPR>ENTER NCP >>> >>> NCP>SHOW STATUS KNOWN LINES >>> >>> NCP> >>> >>> 22:25:11          NCP request # 2 [SHOW STATUS KNOWN LINES] >>> >>> >>> >>>         Status as of 8-May-2013 22:25:12 >>> >>> >>> >>>         Line ID         State           Adjacent Node >>> >>> >>> >>>         KDP_0_0         On >>> >>>         KDP_0_1         On >>> >>>           Function completed successfully >>> >>> NCP> >>> >>> >>> >>> J >>> >>> >>> >>> Regards >>> >>> >>> >>> Rob >>> >>> >>> >> >> I wonder if it would be possible to apply what you've done with TOPS-20 to >> TOPS-10. >> > > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to > install DECnet on TOPS-10 have not gone well so far though, it fails to link > after MONGEN. > That was the same problem I was having. > Regards > > Rob > > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From litt at ieee.org Fri May 10 13:39:26 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 10 May 2013 13:39:26 -0400 Subject: [Simh] [HECnet] TOPS20 4.1 DECnet Progress In-Reply-To: <082101ce4da3$65a76400$30f62c00$@ntlworld.com> References: <06d001ce4c33$2f45cdf0$8dd169d0$@ntlworld.com> <082101ce4da3$65a76400$30f62c00$@ntlworld.com> Message-ID: <518D30CE.2000707@ieee.org> On 10-May-13 13:25, Robert Jarratt wrote: > >> -----Original Message----- >> From: Cory Smelosky [mailto:b4 at gewt.net] >> Sent: 10 May 2013 07:28 >> To: Robert Jarratt >> Cc: simh; hecnet >> Subject: Re: [HECnet] TOPS20 4.1 DECnet Progress >> >> On Wed, 8 May 2013, Robert Jarratt wrote: >> >>> Making progress: >>> >>> >>> >>> $OPR >>> >>> OPR>ENTER NCP >>> >>> NCP>SHOW STATUS KNOWN LINES >>> >>> NCP> >>> >>> 22:25:11 NCP request # 2 [SHOW STATUS KNOWN LINES] >>> >>> >>> >>> Status as of 8-May-2013 22:25:12 >>> >>> >>> >>> Line ID State Adjacent Node >>> >>> >>> >>> KDP_0_0 On >>> >>> KDP_0_1 On >>> >>> Function completed successfully >>> >>> NCP> >>> >>> >>> >>> J >>> >>> >>> >>> Regards >>> >>> >>> >>> Rob >>> >>> >>> >> I wonder if it would be possible to apply what you've done with TOPS-20 to >> TOPS-10. >> > Once I get it working on TOPS-20 then we can try TOPS-10. My own efforts to > install DECnet on TOPS-10 have not gone well so far though, it fails to link > after MONGEN. > > Regards > > Rob Assuming you follow the installation guide and that there's no version skew, any version of TOPS-10 that supports DECnet should build and run out of the box. If you provide the specific version & tape images, commands used and all output, we can advise. Do note that if you are using any unsupported/customer supported modules (e.g. the DMR driver), they need to be obtained from the 'customer supported' tape/directory and added to the build files. This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 04:53:53 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 09:53:53 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <20130508000146.A1B69242BE@panix5.panix.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> Message-ID: <030e01ce546e$67754f00$365fed00$@ntlworld.com> > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Rich Alderson > Sent: 08 May 2013 01:02 > To: hecnet at update.uu.se; simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > From: "Robert Jarratt" > > Date: Tue, 7 May 2013 23:33:36 +0100 > > > Can anyone point me at the right place to look at TOPS-20 driver code > > for the KMC11? I can see that it is trying to get the Microprocessor > > to do something and read back some values, but I don't know what > > values it wants to get and so it reports: > > Hi, Rob, > > http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html > > You want the file KDPSRV.MAC in that directory. > > Rich > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh I am making some progress with getting the KMC/DUP emulation working in SIMH for TOPS-20. At the moment I am stuck on one thing, which is the interrupts to tell the OS that the KMC has processed a buffer. The OS sets the interrupt enable bit and when I have something to report to the OS I set the relevant interrupt bit. However, nothing happens when I do that. I am wondering if I have the right interrupt bit? I am using bits 8 and 9 (decimal). I am not sure how to find out which bit I should be setting. Can anyone help? Regards Rob From litt at ieee.org Sun May 19 05:58:27 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 05:58:27 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <030e01ce546e$67754f00$365fed00$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> Message-ID: <5198A243.8080000@ieee.org> First, remember: COMMENT @ EHPL MI RTPADE NIISED A DP1P1 END OF COMMENT @ Besides setting the correct bit(s), you need to tell simh to generate the interrupt (to the proper vector). Assuming you're doing that, from the KDP's point of view you first need to set rdyo or rdyi, indicate the interrupt directions with iot, the command type, line number... Here are the KDP bit definitions from TOPS-10 , and the most interesting interrupt service code. It's pretty readable; it uses fewer macros than the TOPS-20 driver. The constants are all octal, based as offsets from the CSR base. If you need the other routines, see http://pdp-10.trailing-edge.com/tops10_704_monitoranf_bb-x140c-sb/01/10,7/mon/d8kint.mac.html The KDPAIV and KDPBIV routines are the two generic KDP interrupt service routines; each KDP has small prefix routines that dispatch to them after saving/setting up the registers. The instructions RDIO and WRIO read/write Unibus space. The register address is the second argument, the contents are loaded to / stored from the first argument. If you scan the full source for them, you can see how each register is used. If you need more help, you'll need to provide more details of what is - and isn't - happening. SUBTTL DEFINITIONS -- DUP11 DUPADR==3760300 ;ADDRESS OF 1ST DUP11 DUPUBN==3 ;UNIBUS ADAPTER NUMBER FOR DUP11 DPRCSR==0 ;RECEIVER CSR DPDTR==000002 ;DATA TERMINAL READY DPRDBF==2 ;(RO)RECEIVER DATA BUFFER DPPCSR==2 ;(WO)PARAMETER CONTROL AND STATUS REGISTER DPTCSR==4 ;TRANSMIT CONTROL AND STATUS REGISTER DPCBLP==010000 ;EXTERNAL MAINTENCE MODE (CABLE LOOPBACK) DPCNLP==004000 ;SYSTEMS TEST MODE (CONTROLLER LOOPBACK) DPMAIN==014000 ;MAINTAINENCE MODE BITS DPTDBF==6 ;TRANSMIT DATA BUFFER SUBTTL DEFINITIONS -- KMC11 SEL0==0 BSEL1==1 KMCRUN==100000 ;RUN FLOP KMCMCL==040000 ;MASTER CLEAR KMCCWR==020000 ;CRAM WRITE KMCSLU==010000 ;STEP LINE UNIT KMCLUL==004000 ;LINE UNIT LOOP KMCRMO==002000 ;ROM OUTPUT KMCRMI==001000 ;ROM INPUT KMCSUP==000400 ;STEP u-PROCESSOR KMCRQI==000200 ;REQUEST INPUT KMCIEO==000020 ;INTERRUPT ENABLE OUTPUT KMCIEI==000001 ;INTERRUPT ENABLE INPUT SEL2==2 BSEL3==3 ;CONTAINS LINE NUMBER KMCOVR==100000 ;KMC BUFFER OVER-RUN KMCRDO==000200 ;READY FOR OUTPUT KMCRDI==000020 ;READY FOR INPUT KMCIOT==000004 ;SET FOR RECEIVE CLEARED FOR TRANSMIT KMCTYP==000003 ;COMMAND TYPE BASEIN==000003 ;BASE IN CNTLIN==000001 ;CONTROL IN BFADIN==000000 ;BUFFER ADDRESS IN CNTLOU==000001 ;CONTROL OUT BFADOU==000000 ;BUFFER ADDRESS OUT SEL4==4 BSEL5==5 ;BUFFER DESCRIPTOR LIST ADDRESS ; (BUFFER ADR IN & OUT & CONTROL OUT) SEL6==6 BSEL7==7 ;140000 ;ADR BITS 17 & 16 ; (BUFFER ADR IN & OUT & CONTROL OUT) BFREOM==010000 ;END OF MESSAGE (BUFFER ADR OUT) BFRENB==020000 ;BUFFER ENABLE (BUFFER ADR IN) BFRKIL==010000 ;BUFFER KILL (BUFFER ADR IN) CSRMSK==017770 ;MASK FOR DUP11 CSR ADR (BASE IN) CDDCMP==100000 ;FLAG THIS A DDCMP LINE (CONTROL IN) CHALFD==020000 ;FLAG THIS IS HALF DUPLEX (CONTROL IN) ;010000 ;ENABLE SECONDARY STATION (CONTROL IN) ;001000 ;CRC INHIBIT (CONTROL IN) CENABL==000400 ;FLAG TO ENABLE LINE (CONTROL IN) COUERR==000377 ;ERROR CODE (CONTROL OUT) CRAMSZ==2000 ;SIZE OF KMC11 CRAM DRAMSZ==2000 ;SIZE OF KMC11 DRAM ;BUFFER DESCRIPTOR LISTS ARE STRINGS OF 3 16 BIT WORDS ; 1ST WORD 16 BITS OF BUFFER ADDRESS ; 2ND WORD 16 BIT BYTE COUNT ; 3RD WORD BDLLDS==100000 ;LAST DESCRIPTOR BDLRSY==010000 ;RESYNC TRANSMITTER BDLXAD==006000 ;BUFFER ADDRESS BITS 17 & 16 BDLEOM==001000 ;END OF MESSAGE BDLSOM==000400 ;START OF MESSAGE ;MESSAGES TO THE KMC11 ; BASEIN: BSEL2/ *400+3 ; BSEL6/ &017770 ; CONTROL IN: BSEL2/ *400+1 ; BSEL6/ FLAGS ; BF AD IN: BSEL2/ *400+0+<4 IF INPUT> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ FLAGS ; BF AD OUT: BSEL2/ *400+0+<4 IF RECEIVE> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ FLAGS ; CONTROL OUT: BSEL2/ *400+1+<4 IF RECEIVE> ; BSEL4/ BUFFER DESCRIPTOR LIST ADR ; BSEL6/ ERROR CODE ;CONTROL OUT BIT MASK DEFINITIONS. THE ROUTINE "CTOTLY" TAKES A ; CONTROL OUT CODE, TALLYS THE CONTROL OUT IN THE KDL BLOCK, AND ; PRODUCES A BIT VECTOR OF ONE BIT REPRESENTING THE CODE. THIS ; BIT VECTOR REPRESENTATION IS USED TO FACILITATE PARALLEL TESTING ; FOR VARIOUS CONDITIONS. BIT DEFINITIONS ARE: CTLO06==040000 ;ABORT. SHOULD NEVER HAPPEN CTLO10==020000 ;HEADER CRC ERROR. CTLO12==010000 ;DATA CRC ERROR. CTLO14==004000 ;NO RECEIVE BUFFER ASSIGNED CTLO16==002000 ;DATA SET READY TRANSITION CTLO20==001000 ;KMC-11 GOT A NXM ON A UNIBUS ADDRESS CTLO22==000400 ;TRANSMIT UNDERRUN. CTLO24==000200 ;RECEIVE OVERRUN CTLO26==000100 ;BUFFER KILL COMPLETE SUBTTL INTERRUPTS -- INTERRUPT LEVEL INTERFACE TO THE KMC-11 Comment @ Each KMC-11 has two interrupt vector addresses. "A" This interrupt is taken when RDYI (KMCRDI) comes up. In this state the KMC-11 is ready for an input transaction. All input transactions for the KMC-11 are queued in the KDP block. This is necessary because the following situation would otherwise cause a deadlock. 1) The KMC-11 sets RDYO and gives a BUFFER-OUT transaction. 2) At interrupt level, we want to do a BUFFER-IN. 3) If, in the meantime, the KMC-11 has set RDYO again, we will not be able to get RDYI until we process another output transaction. The solution to this is to queue all input transactions. This does mean that we have to take an interrupt on each transaction, but it does circumvent the above problem. "B" This interrupt is taken when RDYO (KMCRDO) comes up. In this state the KMC-11 is wants to perform an output transaction. It is these output transactions that drive almost all of the interrupt level KMC/DUP processing. The vector instructions are set up to be JSR's to the locations "KDPAIV", and "KDPBIV" in the KDP block for the KMC-11. These locations contain the 5 or 6 instructions necessary to save the AC's, load "W" with the address of the particular KDP block, and dispatch to either of the two interrupt routines "KDPAIV" or "KDPBIV". End comment @ SUBTTL KDPAIV -- KMC-11 INTERRUPT VECTOR "A" PROCESSING. ;KDPAIV -- ROUTINE TO HANDLE KMC-11 INTERRUPT VECTOR "A" (INPUT) ;CALL MOVE W,[EXP KDP-BLOCK-ADDRESS] ; PUSHJ P,KDPAIV ;CALLED FROM KDPIVA IN THE KDP BLOCK ;RETURN POPJ P, ;TO DISMISS THE INTERRUPT. ; ;CLOBBERS MOST AC'S (WE SHOULD HAVE OUR OWN AC BLOCK ANYWAY) ; ;ON MULTI-PROCESSOR SYSTEMS, THIS CODE WILL NEED TO AOSE THE KDP INTERLOCK ; KDPAIV::AOS KDPACT(W) ;COUNT THE INTERRUPT MOVE T1,KDPSTS(W) ;GET THE STATUS TLNN T1,(KDPSRU) ; AND MAKE SURE WE THINK WE'RE ON LINE PJSP T1,KDPERR ; IF WE DON'T, CLEAR "RUN" SO INTS WILL STOP MOVE U,KDPCSR(W) ;GET THE UNIBUS ADDRESS OF THE KMC-11 MOVEI T1,KMCRDI ;GET THE "RDYI" FLAG TION T1,SEL2(U) ;MAKE SURE "RDYI" IS UP PJSP T1,KDPERR ; IF IT'S NOT, THEN ITS AN ILLEGAL INTERRUPT MOVE T3,KDPIQT(W) ;GET NUMBER OF NEXT QUEUED TRANSACTION CAMN T3,KDPIQP(W) ;MAKE SURE THAT IT'S DIFFERENT NOT THE "PUTTER" PJSP T1,KDPERR ; IF IT IS, THEN WE'RE GETTINT UNSOLICITED ; INTERRUPTS. DECLARE KDP ILL. LSH T3,1 ;MAKE IT AN OFFSET INTO THE QUEUE ADDI T3,KDPINQ(W) ;RELOCATE BY THE ADDRESS OF THE QUEUE MOVE T1,0(T3) ;GET SEL2 DATA MOVE T2,1(T3) ;GET SEL4, SEL6 DATA AOS T3,KDPIQT(W) ;ADVANCE QUEUE TAKER CAIL T3,KDPQLN ;IF ITS TIME TO WRAP AROUND, THEN SETZB T3,KDPIQT(W) ; WRAP AROUND TO THE FIRST ENTRY MOVEI T4,KMCRQI ;GET THE REQUEST INPUT INTERRUPT BIT CAMN T3,KDPIQP(W) ;IF QUEUE EMPTY (PUTTER = TAKER) THEN BCIO T4,SEL0(U) ; CLEAR RQI TO STOP THE INTERRUPTS WRIO T2,SEL6(U) ;STORE TOP WORD MOVSS T2,T2 ;GET SEL4 DATA WRIO T2,SEL4(U) ; AND STORE THAT TRZ T1,KMCRDI ;MAKE SURE RDYI CLEAR (SO KMC CAN RUN) WRIO T1,SEL2(U) ;GIVE REST OF DATA TO KMC POPJ P, ;ALL DONE ;KDPBIV -- ROUTINE TO HANDLE KMC-11 INTERRUPT VECTOR "B" (OUTPUT) ;CALL MOVE W,[EXP KDP-BLOCK-ADDRESS] ; PUSHJ P,KDPBIV ;CALLED FROM KDPIVB IN THE KDP BLOCK ;RETURN POPJ P, ;TO DISMISS THE INTERRUPT ; ;CLOBBERS MOST AC'S (WE SHOULD HAVE OUR OWN AC BLOCK ANYWAYS) ; ;ON MULTI-PROCESSOR SYSTEMS THIS CODE WILL NEED TO AOSE THE KDP INTERLOCK. ; KDPBIV::AOS KDPBCT(W) ;COUNT THE INTERRUPT MOVE T1,KDPSTS(W) ;GET OUR PERCEIVED STATUS TLNN T1,(KDPSRU) ; AND MAKE SURE WE THINK WE'RE RUNNING PJSP T1,KDPERR ; IF WE'RE NOT, CLEAR RUN AND RETURN MOVE U,KDPCSR(W) ;GET THE UNIBUS ADDRESS OF THE KMC RDIO P1,SEL2(U) ;READ STATUS BITS TRNN P1,KMCRDO ;BETTER WANT AN OUTPUT TRANSACTION PJSP T1,KDPERR ;ILLEGAL INTERRUPT. CRASH KMC RDIO P2,SEL4(U) ;READ BDL ADDRESS RDIO P3,SEL6(U) ;READ ERROR, STATUS OR WHAT EVER MOVEI T1,KMCRDO ;GET THE RDYO BIT BCIO T1,SEL2(U) ;CLEAR IT TO LET THE KMC CONTINUE TRNE P1,2!KMCOVR ;MAKE SURE TYPE IS RIGHT, AND NO OVERRUN PJSP T1,KDPERR ; WE'RE CONFUSED. GIVE UP. LDB F,[POINT 7,P1,27] ;GET 7 BIT LINE #. CAML F,KDPDPN(W) ;IS THIS A LEGAL LINE FOR THIS KDP PJSP T1,KDPERR ; IF NOT, BETTER STOP NOW... ADDI F,KDPKDL(W) ;MAKE IT AN OFFSET INTO THE KDP BLOCK HRRZ F,(F) ;LOAD APPRIOATE KDL BLOCK ADDRESS SETZ T1, ;GET A ZERO REGISTER TRNE P1,KMCIOT ;IF INPUT, THEN TRO T1,1 ; SET LOW ORDER BIT TRNE P1,1 ;IF CONTROL, THEN TRO T1,2 ; SET NEXT TO LOW ORDER BIT JRST @[JRST KDPBOO ;BUFFER OUT (OUTPUT) JRST KDPBOI ;BUFFER OUT (INPUT) JRST KDPCOO ;CONTROL OUT (OUTPUT) JRST KDPCOI](T1);CONTROL OUT (INPUT) ;ROUTINE DISPATCHED TO WILL RETURN. SUBTTL KDPBOO -- KMC-11 BUFFER-OUT(OUTPUT) TRANSACTION PROCESSING. ; This routine frees output buffers when a BUFFER-OUT(OUTPUT) transaction ;declares that the KMC/DUP has output all data in the buffer. It: ; 1) Makes sure that this is the last buffer in the current ; Buffer Description List. (Data messages consist of two ; buffers. The DDCMP header buffer, and the data buffer. ; These two buffers are combined in a single BDL) If ; the current buffer is not the last in the list, nothing ; more is done, and the interrupt is exited. (We will ; get another interrupt when the next buffer in the BDL ; finishes.) ; 2) The count of buffers outstanding is decremented, and a ; check is made to ensure that this buffer is really the ; next one we expected to finish. ; 3) XMTBUF is called in an attempt to fill the just freed output ; buffer. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPBOO: PUSHJ P,GETBDL ;GET T4 SET UP TO POINT TO BDL TLNE T4,1 ;MAKE SURE THAT BUFFER-OUT STARTS ON EVEN BYTE PJSP T1,KDPERR ; IF ODD BYTE, THEN KMC-11 SCREWED US MOVE T1,1(T4) ;GET WORD WITH LAST BD HALFWORD TLNN T4,2 ;IF WE WANT FIRST HALFWORD, MOVS T1,T1 ; THEN SWAP IT TO THE LOW HALF TRNN T1,BDLLDS ;IS THIS THE LAST BUFFER IN THE BDL POPJ P, ;IF NOT, IGNORE THIS INTERRUPT. ;WE ARE AT END OF MESSAGE. MAKE SURE WE GOT THE RIGHT ONE BACK MOVEI S,KDSNXB ;STATUS BIT THAT SAYS WHICH BUFFER IS NEXT OUT MOVEI T1,KDLXD1(F) ;ASSUME THAT BUFFER #1 IS FIRST BACK TDNE S,KDLSTS(F) ; BUT IF IT SHOULD BE BUFFER #2, THEN MOVEI T1,KDLXD2(F) ; THEN CHANGE OUR MIND. MOVSI T2,(1B0) ;GET THE BDL IN-USE MARK BIT TDNN T2,0(T1) ; AND MAKE SURE THAT IT'S SET ;[DBUG] PJSP T1,KDLERR ;IF NOT, TRY TO CRASH THE LINE PUSHJ P,NTDSTP## ;WE'VE SCREWED UP THE BUFFERS [DBUG] ANDCAM T2,0(T1) ;CLEAR THE USE BIT HLRZ T3,1(T1) ;GET THE HALFWORD CONTAINING THE 3RD WORD ; OF THE FIRST BD IN THE BDL TRNN T3,BDLLDS ;IF IT'S NOT THE LAST BD, THEN ADD T1,[XWD 2,1] ; ADVANCE THE CBP IN T1 3 WORDS (6 BYTES) CAMN T1,T4 ;MAKE SURE IT'S THE BDL ADDRESS THE KMC GAVE US SOSGE KDLXBC(F) ;DECREMENT THE NUMBER OF ACTIVE OUTPUT BUFFERS PJSP T1,KDPERR ;++ EITHER BAD BUFFER, OF COUNT WENT NEGATIVE. XORB S,KDLSTS(F) ;SIGNAL THAT OTHER BUFFER IS NEXT BUFFER OUT PJRST XMTBUF ;NOW GO TRY TO FILL THE JUST FREED BUFFER SUBTTL KDPBOI -- ROUTINE TO HANDLE BUFFER-OUT(INPUT) TRANSACTIONS. ; This routine handles BUFFER-OUT(INPUT) transactions. These ;transactions consist of input messages coming in over the synchronous ;line. This routine: ; 1) Frees the receive buffer. (No worry about races, this ; code runs under the KMC interlock on multiprocessor ; systems. On a single processor system, it runs at ; interrupt level. Hence no one will try to allocate ; the buffer between when it is freed and when it is ; processed ; 2) Calls RCVMSG to process the incoming message ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPBOI: PUSHJ P,FREBOI ;FREE THE INPUT BUFFER, (SET UP T4) PJSP T1,KDPERR ;?? KMC-11 GAVE BAD BDL ADDRESS ?? PJRST RCVMSG ;GO PROCESS MESSAGE (T4 POINTS TO BDL) SUBTTL KDPCOO -- PROCESS A CONTROL-OUT(OUTPUT) TRANSACTION ; This routine processes CONTROL-OUT(OUTPUT) transactions. These ;consist primarily of various errors detected by the KMC-11. This routine: ; 1) Counts the control out transaction code (CTOTLY) ; 2) Verifys that the error is legal/recoverable. If not, ; it crashes the KMC-11. ; 3) If the control out frees an output BDL, it assumes that ; an output message has been clobbered, queues a REP message ; to speed a recovery NAK, and calls "KDPBOO" to free the BDL. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPCOO: PUSHJ P,SAVE1## ;WE USE P1 FOR A "BIT MASK" PUSHJ P,CTOTLY ;TALLY THE CONTROL OUT CODE AND ; PUT "BIT MASK" IN P1 PJSP T1,KDPERR ;IF ILLEGAL CODE, KMC-11 IS SICK... TLNE P1,^- ;THESE ARE LEGAL OUTPUT PJSP T1,KDPERR ; IF IT'S NOT ONE OF THEM, CRASH KMC-11 TLNE P1,CTLO14 ;IS THIS A BUFFER TEMP UNAVAILABLE? JRST [MOVEI T1,RSNBTU ;IF SO, GET THAT NAK CODE PJRST RCVXNK] ;SEND THE NAK AND RETURN TLNE P1,CTLO26 ;IF THIS A "FLUSH DONE" TRANSACTION JRST KDPFLO ; IF FLUSH DONE, GO UPDATE KDLSTS TLNN P1,CTLO22 ;DOES THIS TRANSACTION FREE A BDL? POPJ P, ; IF NOT, RETURN (DON'T CALL XMTBUF...) MOVSI T1,(KDSREP) ;ASSUME MESSAGE WAS CLOBBERED, SO IORM T1,KDLSTS(F) ; SO REQUEST A REP TO SPEED RECOVERY PJRST KDPBOO ;PROCESS REST JUST LIKE ANY OTHER BUFFER-OUT SUBTTL KDPCOI -- PROCESS CONTROL-OUT(INPUT) TRANSACTIONS ; This routine processes the CONTROL-OUT(INPUT) transactions. These ;transactions are primarily errors noticed by the KMC-11. In particular, ;BCC (checksum) errors are processed here. This routine: ; 1) Tallys the CONTROL-OUT transaction ; 2) Sees if it is a legal/recoverable error. If not, it ; crashes the KMC-11 ; 3) If the transaction frees an input buffer, that is done. ; 4) If the transaction implies that a message was lost, ; an approiate NAK is queued. ; ;called with: ; F, W := KDL and KDP pointers ; P1, P2, P3 := SEL2, SEL4 and SEL6 of the KMC-11 ; KDPCOI: PUSHJ P,SAVE1## ;P1 WILL HAVE THE "BIT MASK" IN IT. PUSHJ P,CTOTLY ;TALLY THE CONTROL OUT TYPE ; RETURNS "BIT MASK" IN P1 PJSP T1,KDPERR ;UNKNOWN CODE. KMC-11 IS SICK... TLNE P1,^- ;IS THIS LEGAL FOR INPUT PJSP T1,KDLERR ;UN-RECOVERABLE ERROR. BETTER START OVER TLNE P1,CTLO26 ;IS THIS AN "INPUT FLUSH" DONE TRANSACTION JRST KDPFLI ; IF INPUT FLUSH, GO UPDATE KDLSTS TLNE P1, ;DOES THIS FREE A BDL? PUSHJ P,[PUSHJ P,FREBOI ;FREE THE INPUT BDL PJSP T1,KDLERR ;BAD ADDRESS RETURNED BY KMC-11. DIE POPJ P,] ;RETURN TO MAIN FLOW TLNN P1, ;DOES THIS REQUIRE A NAK? PJRST RCVBUF ;IF NO NAK REQUIRED, WE ARE DONE ; ATTEMPT TO REQUEUE A BUFFER AND RETURN MOVEI T1,RSNHCK ;ASSUME THAT ERROR WAS HEADER CHECKSUM TLNE P1,CTLO12 ; BUT IF IT WAS A DATA CHECKSUM MOVEI T1,RSNDCK ; THEN CHANGE OUR MINDS AND USE THAT TLNE P1,CTLO24 ; UNLESS IT WAS AN OVER-RUN, IN WHICH MOVEI T1,RSNOVR ; CASE WE SHOULD USE THIS. PJRST RCVXNK ;QUEUE NAK AND REQUEUE BUFFERS IF POSSIBLE ;KDPFLO ROUTINE TO CLEAN UP WHEN OUTPUT BUFFER FLUSH IS COMPLETED. ; CLEAR "XMIT FLUSH IN PROGRESS" AND SAY NO OUTPUT BUFFERS QUEUED. KDPFLO: LDB T1,KDLSTA## ;GET THE LINE'S STATE (JUST TO MAKE SURE) MOVEI T2,KDSXFL ;GET THE "XMIT FLUSH" IN PROGRESS BIT CAIN T1,KD%FLS ;IF WE'RE NOT IN "BUFFER FLUSH STATE", OR TDNN T2,KDLSTS(F) ; WE'RE NOT FLUSHING XMIT BUFFERS PJSP T1,KDPERR ; THEN ASSUME THE KMC-11 SCREWED UP SETZM KDLXBC(F) ;SAY "NO OUTPUT BUFFERS ACTIVE" MOVEI T1,KDSNXB!KDSXFL; ALSO SAY THAT NEXT BUFFER IS #0, AND ANDCAB T1,KDLSTS(F) ; WE'RE NOT FLUSHING ANY MORE JRST KDPFLX ;SEE IF WE CAN LEAVE "FLUSH" STATE ;KDPFLI ROUTINE TO CLEAN UP WHEN INPUT BUFFER FLUSH IS COMPLETE KDPFLI: LDB T1,KDLSTA## ;GET LINE'S STATE MOVEI T2,KDSRFL ;"RECEIVE FLUSH IN PROGRESS" BIT CAIN T1,KD%FLS ;MAKE SURE WE'RE FLUSHING TDNN T2,KDLSTS(F) ;MAKE SURE IT'S INPUT PJSP T1,KDPERR ;IF NOT INPUT FLUSH, THEN KMC GAVE BAD CODE SETZM KDLRBC(F) ;ZERO COUNT OF RECEIVE BUFFERS POSTED MOVEI T1,KDSNRB!KDSRFL;SAY BUFFER #0 NEXT, AND ANDCAB T1,KDLSTS(F) ; INPUT FLUSH COMPLETE KDPFLX: MOVEI T2,KD%INI ;ASSUME THAT WE HAVE CLEARED BOTH FLUSH BITS TRNN T1,KDSRFL!KDSXFL; AND IF WE HAVE, DPB T2,KDLSTA## ; THEN WE'RE IN "INITED" STATE POPJ P, ;DONE WITH THE INTERRUPT This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 04:53, Robert Jarratt wrote: >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Rich Alderson >> Sent: 08 May 2013 01:02 >> To: hecnet at update.uu.se; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >>> From: "Robert Jarratt" >>> Date: Tue, 7 May 2013 23:33:36 +0100 >>> Can anyone point me at the right place to look at TOPS-20 driver code >>> for the KMC11? I can see that it is trying to get the Microprocessor >>> to do something and read back some values, but I don't know what >>> values it wants to get and so it reports: >> Hi, Rob, >> >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >> >> You want the file KDPSRV.MAC in that directory. >> >> Rich >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > I am making some progress with getting the KMC/DUP emulation working in SIMH > for TOPS-20. At the moment I am stuck on one thing, which is the interrupts > to tell the OS that the KMC has processed a buffer. The OS sets the > interrupt enable bit and when I have something to report to the OS I set the > relevant interrupt bit. However, nothing happens when I do that. I am > wondering if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). > > I am not sure how to find out which bit I should be setting. > > Can anyone help? > > Regards > > Rob > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Sun May 19 06:26:14 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 06:26:14 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <030e01ce546e$67754f00$365fed00$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> Message-ID: <5198A8C6.7030706@ieee.org> A couple of other things come to mind (naturally, after pushing 'send'): Initialization will load/verify the microcode. That has to work. After setting RUN and the interrupt enables, expect base-in and control-in command to establish the DUP CSR address, buffers, line mode/enable. These require that the KMC respond to KMCRQI by initiating an A vector interrupt. Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit clear (BCIO) instructions that also touch the KMC. For better directed hints, I'd need more detail on what is and isn't happening. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 04:53, Robert Jarratt wrote: >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Rich Alderson >> Sent: 08 May 2013 01:02 >> To: hecnet at update.uu.se; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >>> From: "Robert Jarratt" >>> Date: Tue, 7 May 2013 23:33:36 +0100 >>> Can anyone point me at the right place to look at TOPS-20 driver code >>> for the KMC11? I can see that it is trying to get the Microprocessor >>> to do something and read back some values, but I don't know what >>> values it wants to get and so it reports: >> Hi, Rob, >> >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >> >> You want the file KDPSRV.MAC in that directory. >> >> Rich >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > I am making some progress with getting the KMC/DUP emulation working in SIMH > for TOPS-20. At the moment I am stuck on one thing, which is the interrupts > to tell the OS that the KMC has processed a buffer. The OS sets the > interrupt enable bit and when I have something to report to the OS I set the > relevant interrupt bit. However, nothing happens when I do that. I am > wondering if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). > > I am not sure how to find out which bit I should be setting. > > Can anyone help? > > Regards > > Rob > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 07:42:59 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 12:42:59 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198A8C6.7030706@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> Message-ID: <034b01ce5486$06b04810$1410d830$@ntlworld.com> Thanks Timothe, I am pretty sure I am doing all the things you mention already (sorry I didn't make that clear), but I will check through everything you have said, just in case I have missed something. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 11:26 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > A couple of other things come to mind (naturally, after pushing 'send'): > > Initialization will load/verify the microcode. That has to work. > > After setting RUN and the interrupt enables, expect base-in and control-in > command to establish the DUP CSR address, buffers, line mode/enable. > These require that the KMC respond to KMCRQI by initiating an A vector > interrupt. > > Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit clear > (BCIO) instructions that also touch the KMC. > > For better directed hints, I'd need more detail on what is and isn't happening. > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 04:53, Robert Jarratt wrote: > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Rich Alderson > >> Sent: 08 May 2013 01:02 > >> To: hecnet at update.uu.se; simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >>> From: "Robert Jarratt" > >>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>> right place to look at TOPS-20 driver code for the KMC11? I can see > >>> that it is trying to get the Microprocessor to do something and read > >>> back some values, but I don't know what values it wants to get and > >>> so it reports: > >> Hi, Rob, > >> > >> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html > >> > >> You want the file KDPSRV.MAC in that directory. > >> > >> Rich > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > I am making some progress with getting the KMC/DUP emulation working > > in SIMH for TOPS-20. At the moment I am stuck on one thing, which is > > the interrupts to tell the OS that the KMC has processed a buffer. The > > OS sets the interrupt enable bit and when I have something to report > > to the OS I set the relevant interrupt bit. However, nothing happens > > when I do that. I am wondering if I have the right interrupt bit? I am > > using bits 8 and 9 (decimal). > > > > I am not sure how to find out which bit I should be setting. > > > > Can anyone help? > > > > Regards > > > > Rob > > > > _______________________________________________ > > Simh mailing list > > Simh at trailing-edge.com > > http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Sun May 19 09:54:10 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 09:54:10 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <034b01ce5486$06b04810$1410d830$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> Message-ID: <5198D982.80809@ieee.org> > I am pretty sure I am doing all the things you mention already Then I need a trace of what's happening to the registers, and what simh thinks it's doing with the interrupts. (It would be easiest to follow if you output both octal and decode the register names/fields, though I can still think - slowly- in octal.) Also, I thought this code was working for the -11/VAX. If so, the basics must be OK, though the drivers may well take a different approach to the device. Received data should produce either a control-out (error, e.g. no buffer available or DSR change or NXM...) or a buffer-out B interrupt. The message must fit in 1 buffer. Errors may implicitly free a BDL... Transmit done - also note that we ignore interrupts unless the 'last buffer' bit is set. (The DDCMP header and data are in two BDL segments, and require two interrupts.) Finally, I'm not sure if you'll see it used, but there is code in the TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to force the microcontroller to execute several known instructions - to access its data ram, registers & PC. This is primarily used to dump a KMC that halts - it doesn't seem to be used when the built-in ucode is loaded. But some of these are also used to verify data ram at initialization. Failure to verify will cause the device to be disabled. We can go down that path if you see those bits being set in a trace. Look for KMCXCT calls in http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor-sources/kdpsrv.mac.html TOPS-10 doesn't do this. The microinstructions are defined in http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP-PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Manual.pdf The subset is pretty small - load address register, load/store indirect (with increment), & branch. I think you ought to be able to crash simh if an unknown instruction is forced, including a branch to an address other than 0. Ugly device, ugly driver. Sigh. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 07:42, Robert Jarratt wrote: > Thanks Timothe, > > I am pretty sure I am doing all the things you mention already (sorry I > didn't make that clear), but I will check through everything you have said, > just in case I have missed something. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Timothe Litt >> Sent: 19 May 2013 11:26 >> To: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> A couple of other things come to mind (naturally, after pushing 'send'): >> >> Initialization will load/verify the microcode. That has to work. >> >> After setting RUN and the interrupt enables, expect base-in and control-in >> command to establish the DUP CSR address, buffers, line mode/enable. >> These require that the KMC respond to KMCRQI by initiating an A vector >> interrupt. >> >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and bit > clear >> (BCIO) instructions that also touch the KMC. >> >> For better directed hints, I'd need more detail on what is and isn't > happening. >> This communication may not represent my employer's views, if any, on the >> matters discussed. >> >> On 19-May-13 04:53, Robert Jarratt wrote: >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Rich Alderson >>>> Sent: 08 May 2013 01:02 >>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>>> From: "Robert Jarratt" >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>> right place to look at TOPS-20 driver code for the KMC11? I can see >>>>> that it is trying to get the Microprocessor to do something and read >>>>> back some values, but I don't know what values it wants to get and >>>>> so it reports: >>>> Hi, Rob, >>>> >>>> http://pdp-10.trailing-edge.com/tops20v41_monitor_sources/index.html >>>> >>>> You want the file KDPSRV.MAC in that directory. >>>> >>>> Rich >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>> I am making some progress with getting the KMC/DUP emulation working >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which is >>> the interrupts to tell the OS that the KMC has processed a buffer. The >>> OS sets the interrupt enable bit and when I have something to report >>> to the OS I set the relevant interrupt bit. However, nothing happens >>> when I do that. I am wondering if I have the right interrupt bit? I am >>> using bits 8 and 9 (decimal). >>> >>> I am not sure how to find out which bit I should be setting. >>> >>> Can anyone help? >>> >>> Regards >>> >>> Rob >>> >>> _______________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 10:20:40 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 15:20:40 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198D982.80809@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> Message-ID: <035801ce549c$0d6c3630$2844a290$@ntlworld.com> I have made some progress. I realised that I did not have the interrupt acknowledgement routines set up in the DIB. It is working a bit better now. I have indeed seen some commands to read the ram and verify the microcode, it does all this to check the KMC is working before enabling it. This particular code has never (as far as I know) worked for the 11 or the VAX. I wrote the DMC11 code for those. This code I am working with now came from someone else and was written for the PDP1) for a much older version of SIMH. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 14:54 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > I am pretty sure I am doing all the things you mention already > Then I need a trace of what's happening to the registers, and what simh > thinks it's doing with the interrupts. (It would be easiest to follow > if you output both octal and decode the register names/fields, though I can > still think - slowly- in octal.) > > Also, I thought this code was working for the -11/VAX. If so, the basics must > be OK, though the drivers may well take a different approach to the device. > > Received data should produce either a control-out (error, e.g. no buffer > available or DSR change or NXM...) or a buffer-out B interrupt. The message > must fit in 1 buffer. Errors may implicitly free a BDL... > > Transmit done - also note that we ignore interrupts unless the 'last buffer' bit > is set. (The DDCMP header and data are in two BDL segments, and require > two interrupts.) > > Finally, I'm not sure if you'll see it used, but there is code in the > TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to > force the microcontroller to execute several known instructions - to access its > data ram, registers & PC. This is primarily used to dump a KMC that halts - it > doesn't seem to be used when the built-in ucode is loaded. But some of > these are also used to verify data ram at initialization. Failure to verify will > cause the device to be disabled. We can go down that path if you see those > bits being set in a trace. > > Look for KMCXCT calls in > http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > sources/kdpsrv.mac.html > TOPS-10 doesn't do this. The microinstructions are defined in > http://bitsavers.trailing- > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > nual.pdf > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > 0Manual.pdf> > The subset is pretty small - load address register, load/store indirect (with > increment), & branch. I think you ought to be able to crash simh if an > unknown instruction is forced, including a branch to an address other than 0. > > Ugly device, ugly driver. Sigh. > > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 07:42, Robert Jarratt wrote: > > Thanks Timothe, > > > > I am pretty sure I am doing all the things you mention already (sorry > > I didn't make that clear), but I will check through everything you > > have said, just in case I have missed something. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Timothe Litt > >> Sent: 19 May 2013 11:26 > >> To: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> A couple of other things come to mind (naturally, after pushing 'send'): > >> > >> Initialization will load/verify the microcode. That has to work. > >> > >> After setting RUN and the interrupt enables, expect base-in and > >> control-in command to establish the DUP CSR address, buffers, line > mode/enable. > >> These require that the KMC respond to KMCRQI by initiating an A > >> vector interrupt. > >> > >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) and > >> bit > > clear > >> (BCIO) instructions that also touch the KMC. > >> > >> For better directed hints, I'd need more detail on what is and isn't > > happening. > >> This communication may not represent my employer's views, if any, on > >> the matters discussed. > >> > >> On 19-May-13 04:53, Robert Jarratt wrote: > >>>> -----Original Message----- > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>> edge.com] On Behalf Of Rich Alderson > >>>> Sent: 08 May 2013 01:02 > >>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>> > >>>>> From: "Robert Jarratt" > >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>>>> right place to look at TOPS-20 driver code for the KMC11? I can > >>>>> see that it is trying to get the Microprocessor to do something > >>>>> and read back some values, but I don't know what values it wants > >>>>> to get and so it reports: > >>>> Hi, Rob, > >>>> > >>>> http://pdp-10.trailing- > edge.com/tops20v41_monitor_sources/index.htm > >>>> l > >>>> > >>>> You want the file KDPSRV.MAC in that directory. > >>>> > >>>> > >>>> Rich _______________________________________________ > >>>> Simh mailing list > >>>> Simh at trailing-edge.com > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>> I am making some progress with getting the KMC/DUP emulation > working > >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which is > >>> the interrupts to tell the OS that the KMC has processed a buffer. > >>> The OS sets the interrupt enable bit and when I have something to > >>> report to the OS I set the relevant interrupt bit. However, nothing > >>> happens when I do that. I am wondering if I have the right interrupt > >>> bit? I am using bits 8 and 9 (decimal). > >>> > >>> I am not sure how to find out which bit I should be setting. > >>> > >>> Can anyone help? > >>> > >>> Regards > >>> > >>> Rob > >>> > >>> _______________________________________________ > >>> Simh mailing list > >>> Simh at trailing-edge.com > >>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 19 11:01:28 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 16:01:28 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <035801ce549c$0d6c3630$2844a290$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> Message-ID: <036601ce54a1$c1719f80$4454de80$@ntlworld.com> What is curious now is that I have two instances (identical clones) running attempting to talk to each other. The first message one sends to the other crashes the OS: ********** *BUGHLT "KMCIII" AT 19-May-2013 15: *ADDITIONAL DATA: 000000172507, 000000000200 ********** The odd thing is that I have delivered the same data that was sent from the other end, so it should be valid data. The data is: 05 06 C0 00 00 01 That data does not seem to completely match the DDCMP spec I have, I think some checksum is supposed to follow. Is that supposed to be added by the KMC perhaps? I don't fully expect it to work because they are clones so would expect some kind of error, but would not expect a crash, or am I wrong? Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Robert Jarratt > Sent: 19 May 2013 15:21 > To: 'Timothe Litt'; simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > I have made some progress. I realised that I did not have the interrupt > acknowledgement routines set up in the DIB. It is working a bit better now. > > I have indeed seen some commands to read the ram and verify the > microcode, it does all this to check the KMC is working before enabling it. > > This particular code has never (as far as I know) worked for the 11 or the > VAX. I wrote the DMC11 code for those. This code I am working with now > came from someone else and was written for the PDP1) for a much older > version of SIMH. > > Regards > > Rob > > > -----Original Message----- > > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > edge.com] On Behalf Of Timothe Litt > > Sent: 19 May 2013 14:54 > > To: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > I am pretty sure I am doing all the things you mention already > > Then I need a trace of what's happening to the registers, and what simh > > thinks it's doing with the interrupts. (It would be easiest to follow > > if you output both octal and decode the register names/fields, though > > I > can > > still think - slowly- in octal.) > > > > Also, I thought this code was working for the -11/VAX. If so, the > > basics > must > > be OK, though the drivers may well take a different approach to the > device. > > > > Received data should produce either a control-out (error, e.g. no > > buffer available or DSR change or NXM...) or a buffer-out B interrupt. > > The > message > > must fit in 1 buffer. Errors may implicitly free a BDL... > > > > Transmit done - also note that we ignore interrupts unless the 'last > buffer' bit > > is set. (The DDCMP header and data are in two BDL segments, and > > require two interrupts.) > > > > Finally, I'm not sure if you'll see it used, but there is code in the > > TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to > > force the microcontroller to execute several known instructions - to > access its > > data ram, registers & PC. This is primarily used to dump a KMC that > > halts > - it > > doesn't seem to be used when the built-in ucode is loaded. But some > > of these are also used to verify data ram at initialization. Failure > > to > verify will > > cause the device to be disabled. We can go down that path if you see > those > > bits being set in a trace. > > > > Look for KMCXCT calls in > > http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > sources/kdpsrv.mac.html > > TOPS-10 doesn't do this. The microinstructions are defined in > > http://bitsavers.trailing- > > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > nual.pdf > > > edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > 0Manual.pdf> > > The subset is pretty small - load address register, load/store > > indirect > (with > > increment), & branch. I think you ought to be able to crash simh if > > an unknown instruction is forced, including a branch to an address > > other than > 0. > > > > Ugly device, ugly driver. Sigh. > > > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 07:42, Robert Jarratt wrote: > > > Thanks Timothe, > > > > > > I am pretty sure I am doing all the things you mention already > > > (sorry I didn't make that clear), but I will check through > > > everything you have said, just in case I have missed something. > > > > > > Regards > > > > > > Rob > > > > > >> -----Original Message----- > > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > >> edge.com] On Behalf Of Timothe Litt > > >> Sent: 19 May 2013 11:26 > > >> To: simh at trailing-edge.com > > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> A couple of other things come to mind (naturally, after pushing > 'send'): > > >> > > >> Initialization will load/verify the microcode. That has to work. > > >> > > >> After setting RUN and the interrupt enables, expect base-in and > > >> control-in command to establish the DUP CSR address, buffers, line > > mode/enable. > > >> These require that the KMC respond to KMCRQI by initiating an A > > >> vector interrupt. > > >> > > >> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) > > >> and bit > > > clear > > >> (BCIO) instructions that also touch the KMC. > > >> > > >> For better directed hints, I'd need more detail on what is and > > >> isn't > > > happening. > > >> This communication may not represent my employer's views, if any, > > >> on the matters discussed. > > >> > > >> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>> -----Original Message----- > > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>> edge.com] On Behalf Of Rich Alderson > > >>>> Sent: 08 May 2013 01:02 > > >>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>> > > >>>>> From: "Robert Jarratt" > > >>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > > >>>>> right place to look at TOPS-20 driver code for the KMC11? I can > > >>>>> see that it is trying to get the Microprocessor to do something > > >>>>> and read back some values, but I don't know what values it wants > > >>>>> to get and so it reports: > > >>>> Hi, Rob, > > >>>> > > >>>> http://pdp-10.trailing- > > edge.com/tops20v41_monitor_sources/index.htm > > >>>> l > > >>>> > > >>>> You want the file KDPSRV.MAC in that directory. > > >>>> > > >>>> > > >>>> Rich _______________________________________________ > > >>>> Simh mailing list > > >>>> Simh at trailing-edge.com > > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>> I am making some progress with getting the KMC/DUP emulation > > working > > >>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which > > >>> is the interrupts to tell the OS that the KMC has processed a buffer. > > >>> The OS sets the interrupt enable bit and when I have something to > > >>> report to the OS I set the relevant interrupt bit. However, > > >>> nothing happens when I do that. I am wondering if I have the right > > >>> interrupt bit? I am using bits 8 and 9 (decimal). > > >>> > > >>> I am not sure how to find out which bit I should be setting. > > >>> > > >>> Can anyone help? > > >>> > > >>> Regards > > >>> > > >>> Rob > > >>> > > >>> _______________________________________________ > > >>> Simh mailing list > > >>> Simh at trailing-edge.com > > >>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From litt at ieee.org Sun May 19 12:01:02 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 12:01:02 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <036601ce54a1$c1719f80$4454de80$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> Message-ID: <5198F73E.803@ieee.org> The bugcheck is saying that the RDYO is set, but not RDYI on an A interrupt. (KMCRDI is 20; RDO is 200) RDYO should always go to IVB; RDYI to IVA. Since we took an IVA interrupt, the driver thinks its trying to give the KMC a command, but the interrupt is going to the wrong vector since RDYI is not set. So either you're generating an IVA but setting the wrong status bit, or generating an Ivb event but not to the right vector. Or perhaps you have an overrun - the interrupt has to be cleared when the drive clears the RDx bit. The data looks like a DDCMP start, less the CRCs. That indicates that a fair bit of stuff is working; this is the data that the -10 provides to the KMC. Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. CRC errors are reported by control out bits. Since the KMC both adds on transmit and removes/checks on receive, and you are running over an error-checked transport, you can get away with not simulating this - unless you want to interoperate with an interface that does add the CRCs. Even if the systems are cloned, the DDCMP layer should come up; you'll die later when transport detects a duplicate DECnet node number. This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 11:01, Robert Jarratt wrote: > What is curious now is that I have two instances (identical clones) running > attempting to talk to each other. The first message one sends to the other > crashes the OS: > > ********** > *BUGHLT "KMCIII" AT 19-May-2013 15: > *ADDITIONAL DATA: 000000172507, 000000000200 > ********** > > The odd thing is that I have delivered the same data that was sent from the > other end, so it should be valid data. > > The data is: 05 06 C0 00 00 01 > > That data does not seem to completely match the DDCMP spec I have, I think > some checksum is supposed to follow. Is that supposed to be added by the KMC > perhaps? > > I don't fully expect it to work because they are clones so would expect some > kind of error, but would not expect a crash, or am I wrong? > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Robert Jarratt >> Sent: 19 May 2013 15:21 >> To: 'Timothe Litt'; simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> I have made some progress. I realised that I did not have the interrupt >> acknowledgement routines set up in the DIB. It is working a bit better > now. >> I have indeed seen some commands to read the ram and verify the >> microcode, it does all this to check the KMC is working before enabling > it. >> This particular code has never (as far as I know) worked for the 11 or the >> VAX. I wrote the DMC11 code for those. This code I am working with now >> came from someone else and was written for the PDP1) for a much older >> version of SIMH. >> >> Regards >> >> Rob >> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>> edge.com] On Behalf Of Timothe Litt >>> Sent: 19 May 2013 14:54 >>> To: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>>> I am pretty sure I am doing all the things you mention already >>> Then I need a trace of what's happening to the registers, and what simh >>> thinks it's doing with the interrupts. (It would be easiest to follow >>> if you output both octal and decode the register names/fields, though >>> I >> can >>> still think - slowly- in octal.) >>> >>> Also, I thought this code was working for the -11/VAX. If so, the >>> basics >> must >>> be OK, though the drivers may well take a different approach to the >> device. >>> Received data should produce either a control-out (error, e.g. no >>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. >>> The >> message >>> must fit in 1 buffer. Errors may implicitly free a BDL... >>> >>> Transmit done - also note that we ignore interrupts unless the 'last >> buffer' bit >>> is set. (The DDCMP header and data are in two BDL segments, and >>> require two interrupts.) >>> >>> Finally, I'm not sure if you'll see it used, but there is code in the >>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) to >>> force the microcontroller to execute several known instructions - to >> access its >>> data ram, registers & PC. This is primarily used to dump a KMC that >>> halts >> - it >>> doesn't seem to be used when the built-in ucode is loaded. But some >>> of these are also used to verify data ram at initialization. Failure >>> to >> verify will >>> cause the device to be disabled. We can go down that path if you see >> those >>> bits being set in a trace. >>> >>> Look for KMCXCT calls in >>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>> sources/kdpsrv.mac.html >>> TOPS-10 doesn't do this. The microinstructions are defined in >>> http://bitsavers.trailing- >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>> nual.pdf >>> >> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>> 0Manual.pdf> >>> The subset is pretty small - load address register, load/store >>> indirect >> (with >>> increment), & branch. I think you ought to be able to crash simh if >>> an unknown instruction is forced, including a branch to an address >>> other than >> 0. >>> Ugly device, ugly driver. Sigh. >>> >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 07:42, Robert Jarratt wrote: >>>> Thanks Timothe, >>>> >>>> I am pretty sure I am doing all the things you mention already >>>> (sorry I didn't make that clear), but I will check through >>>> everything you have said, just in case I have missed something. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 11:26 >>>>> To: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> A couple of other things come to mind (naturally, after pushing >> 'send'): >>>>> Initialization will load/verify the microcode. That has to work. >>>>> >>>>> After setting RUN and the interrupt enables, expect base-in and >>>>> control-in command to establish the DUP CSR address, buffers, line >>> mode/enable. >>>>> These require that the KMC respond to KMCRQI by initiating an A >>>>> vector interrupt. >>>>> >>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) >>>>> and bit >>>> clear >>>>> (BCIO) instructions that also touch the KMC. >>>>> >>>>> For better directed hints, I'd need more detail on what is and >>>>> isn't >>>> happening. >>>>> This communication may not represent my employer's views, if any, >>>>> on the matters discussed. >>>>> >>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>> Sent: 08 May 2013 01:02 >>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>>> From: "Robert Jarratt" >>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can >>>>>>>> see that it is trying to get the Microprocessor to do something >>>>>>>> and read back some values, but I don't know what values it wants >>>>>>>> to get and so it reports: >>>>>>> Hi, Rob, >>>>>>> >>>>>>> http://pdp-10.trailing- >>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>> l >>>>>>> >>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>> >>>>>>> >>>>>>> Rich _______________________________________________ >>>>>>> Simh mailing list >>>>>>> Simh at trailing-edge.com >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>> I am making some progress with getting the KMC/DUP emulation >>> working >>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which >>>>>> is the interrupts to tell the OS that the KMC has processed a > buffer. >>>>>> The OS sets the interrupt enable bit and when I have something to >>>>>> report to the OS I set the relevant interrupt bit. However, >>>>>> nothing happens when I do that. I am wondering if I have the right >>>>>> interrupt bit? I am using bits 8 and 9 (decimal). >>>>>> >>>>>> I am not sure how to find out which bit I should be setting. >>>>>> >>>>>> Can anyone help? >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>> _______________________________________________ >>>>>> Simh mailing list >>>>>> Simh at trailing-edge.com >>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 12:36:32 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 17:36:32 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5198F73E.803@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> Message-ID: <037901ce54af$0b17c440$21474cc0$@ntlworld.com> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, not an A, so that would make sense. I have A vectored at bit 8, and B at bit 9. Are you referring to this code: ;HERE FOR INPUT INTERRUPTS KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG MOVEI 17,KMCACS ;BUILD BLT POINTER BLT 17,KMCACS+16 ;SAVE REST OF REGS MOVE P,[-40,,KMCIPL] ;SET UP STACK MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW RDIO T2,BSEL2(T4) ;GET RDI FLAG MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? TRNN T2,KMCRDI ;AND IS IT READY ? BUG (KMCIII,<,>) CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT FLAG CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY If so, then despite the fact that I am setting bit 9 in the interrupt request, it seems to be going to the A interrupt handler. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 17:01 > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > The bugcheck is saying that the RDYO is set, but not RDYI on an A interrupt. > (KMCRDI is 20; RDO is 200) > > RDYO should always go to IVB; RDYI to IVA. > > Since we took an IVA interrupt, the driver thinks its trying to give the KMC a > command, but the interrupt is going to the wrong vector since RDYI is not set. > So either you're generating an IVA but setting the wrong status bit, or > generating an Ivb event but not to the right vector. Or perhaps you have an > overrun - the interrupt has to be cleared when the drive clears the RDx bit. > > The data looks like a DDCMP start, less the CRCs. That indicates that a fair bit > of stuff is working; this is the data that the -10 provides to the KMC. > > Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and > data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > CRC errors are reported by control out bits. Since the KMC both adds on > transmit and removes/checks on receive, and you are running over an error- > checked transport, you can get away with not simulating this - unless you > want to interoperate with an interface that does add the CRCs. > > Even if the systems are cloned, the DDCMP layer should come up; you'll die > later when transport detects a duplicate DECnet node number. > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 19-May-13 11:01, Robert Jarratt wrote: > > What is curious now is that I have two instances (identical clones) running > > attempting to talk to each other. The first message one sends to the other > > crashes the OS: > > > > ********** > > *BUGHLT "KMCIII" AT 19-May-2013 15: > > *ADDITIONAL DATA: 000000172507, 000000000200 > > ********** > > > > The odd thing is that I have delivered the same data that was sent from the > > other end, so it should be valid data. > > > > The data is: 05 06 C0 00 00 01 > > > > That data does not seem to completely match the DDCMP spec I have, I > think > > some checksum is supposed to follow. Is that supposed to be added by the > KMC > > perhaps? > > > > I don't fully expect it to work because they are clones so would expect > some > > kind of error, but would not expect a crash, or am I wrong? > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Robert Jarratt > >> Sent: 19 May 2013 15:21 > >> To: 'Timothe Litt'; simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> I have made some progress. I realised that I did not have the interrupt > >> acknowledgement routines set up in the DIB. It is working a bit better > > now. > >> I have indeed seen some commands to read the ram and verify the > >> microcode, it does all this to check the KMC is working before enabling > > it. > >> This particular code has never (as far as I know) worked for the 11 or the > >> VAX. I wrote the DMC11 code for those. This code I am working with now > >> came from someone else and was written for the PDP1) for a much older > >> version of SIMH. > >> > >> Regards > >> > >> Rob > >> > >>> -----Original Message----- > >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >>> edge.com] On Behalf Of Timothe Litt > >>> Sent: 19 May 2013 14:54 > >>> To: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>>> I am pretty sure I am doing all the things you mention already > >>> Then I need a trace of what's happening to the registers, and what simh > >>> thinks it's doing with the interrupts. (It would be easiest to follow > >>> if you output both octal and decode the register names/fields, though > >>> I > >> can > >>> still think - slowly- in octal.) > >>> > >>> Also, I thought this code was working for the -11/VAX. If so, the > >>> basics > >> must > >>> be OK, though the drivers may well take a different approach to the > >> device. > >>> Received data should produce either a control-out (error, e.g. no > >>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. > >>> The > >> message > >>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>> > >>> Transmit done - also note that we ignore interrupts unless the 'last > >> buffer' bit > >>> is set. (The DDCMP header and data are in two BDL segments, and > >>> require two interrupts.) > >>> > >>> Finally, I'm not sure if you'll see it used, but there is code in the > >>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) > to > >>> force the microcontroller to execute several known instructions - to > >> access its > >>> data ram, registers & PC. This is primarily used to dump a KMC that > >>> halts > >> - it > >>> doesn't seem to be used when the built-in ucode is loaded. But some > >>> of these are also used to verify data ram at initialization. Failure > >>> to > >> verify will > >>> cause the device to be disabled. We can go down that path if you see > >> those > >>> bits being set in a trace. > >>> > >>> Look for KMCXCT calls in > >>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>> sources/kdpsrv.mac.html > >>> TOPS-10 doesn't do this. The microinstructions are defined in > >>> http://bitsavers.trailing- > >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>> nual.pdf > >>> >>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>> 0Manual.pdf> > >>> The subset is pretty small - load address register, load/store > >>> indirect > >> (with > >>> increment), & branch. I think you ought to be able to crash simh if > >>> an unknown instruction is forced, including a branch to an address > >>> other than > >> 0. > >>> Ugly device, ugly driver. Sigh. > >>> > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>> Thanks Timothe, > >>>> > >>>> I am pretty sure I am doing all the things you mention already > >>>> (sorry I didn't make that clear), but I will check through > >>>> everything you have said, just in case I have missed something. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>>> edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 11:26 > >>>>> To: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> A couple of other things come to mind (naturally, after pushing > >> 'send'): > >>>>> Initialization will load/verify the microcode. That has to work. > >>>>> > >>>>> After setting RUN and the interrupt enables, expect base-in and > >>>>> control-in command to establish the DUP CSR address, buffers, line > >>> mode/enable. > >>>>> These require that the KMC respond to KMCRQI by initiating an A > >>>>> vector interrupt. > >>>>> > >>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) > >>>>> and bit > >>>> clear > >>>>> (BCIO) instructions that also touch the KMC. > >>>>> > >>>>> For better directed hints, I'd need more detail on what is and > >>>>> isn't > >>>> happening. > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>> Sent: 08 May 2013 01:02 > >>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>>> From: "Robert Jarratt" > >>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the > >>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can > >>>>>>>> see that it is trying to get the Microprocessor to do something > >>>>>>>> and read back some values, but I don't know what values it wants > >>>>>>>> to get and so it reports: > >>>>>>> Hi, Rob, > >>>>>>> > >>>>>>> http://pdp-10.trailing- > >>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>> l > >>>>>>> > >>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>> > >>>>>>> > >>>>>>> Rich _______________________________________________ > >>>>>>> Simh mailing list > >>>>>>> Simh at trailing-edge.com > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>> I am making some progress with getting the KMC/DUP emulation > >>> working > >>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which > >>>>>> is the interrupts to tell the OS that the KMC has processed a > > buffer. > >>>>>> The OS sets the interrupt enable bit and when I have something to > >>>>>> report to the OS I set the relevant interrupt bit. However, > >>>>>> nothing happens when I do that. I am wondering if I have the right > >>>>>> interrupt bit? I am using bits 8 and 9 (decimal). > >>>>>> > >>>>>> I am not sure how to find out which bit I should be setting. > >>>>>> > >>>>>> Can anyone help? > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Simh mailing list > >>>>>> Simh at trailing-edge.com > >>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >> > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Sun May 19 13:01:01 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 13:01:01 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <037901ce54af$0b17c440$21474cc0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> Message-ID: <5199054D.2030909@ieee.org> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT "KMCIII". You need to tell simh what vector to use when you tell it about the pending interrupt. Most devices have only one vector. The KMC (and DMC/DMR) have 2. A is the (numerically) first; B is the second. So in the interrupt ack routine, you need to return VEC_KDP * kmcnumber or VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. (Or whatever symbol you used.) A should be generated by RDI; B by RDO. That will tell simh how to find the right service routine. IIRC, if both happen to be pending at the same time, A takes precedence. Without seeing the code, I can't be more explicit... Oh, be careful when you talk about bit numbers. The unibus is little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 12:36, Robert Jarratt wrote: > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, not an > A, so that would make sense. I have A vectored at bit 8, and B at bit 9. > > Are you referring to this code: > > ;HERE FOR INPUT INTERRUPTS > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > MOVEI 17,KMCACS ;BUILD BLT POINTER > BLT 17,KMCACS+16 ;SAVE REST OF REGS > MOVE P,[-40,,KMCIPL] ;SET UP STACK > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > RDIO T2,BSEL2(T4) ;GET RDI FLAG > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > TRNN T2,KMCRDI ;AND IS IT READY ? > BUG (KMCIII,<,>) << A interrupt with nothing in the driver queue, or RDI not set > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT FLAG << CSR BIT requesting an A interrupt > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request when driver queue empty > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > << the command is then removed from the driver queue and written to the KMC. The KMC << must clear RDI until it is ready to take the next command. (Note that otherwise if the queue depth >1, the << A interrupt will happen immediately. > If so, then despite the fact that I am setting bit 9 in the interrupt > request, it seems to be going to the A interrupt handler. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Timothe Litt >> Sent: 19 May 2013 17:01 >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > interrupt. >> (KMCRDI is 20; RDO is 200) >> >> RDYO should always go to IVB; RDYI to IVA. >> >> Since we took an IVA interrupt, the driver thinks its trying to give the > KMC a >> command, but the interrupt is going to the wrong vector since RDYI is not > set. >> So either you're generating an IVA but setting the wrong status bit, or >> generating an Ivb event but not to the right vector. Or perhaps you have > an >> overrun - the interrupt has to be cleared when the drive clears the RDx > bit. >> The data looks like a DDCMP start, less the CRCs. That indicates that a > fair bit >> of stuff is working; this is the data that the -10 provides to the KMC. >> >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >> CRC errors are reported by control out bits. Since the KMC both adds on >> transmit and removes/checks on receive, and you are running over an error- >> checked transport, you can get away with not simulating this - unless you >> want to interoperate with an interface that does add the CRCs. >> >> Even if the systems are cloned, the DDCMP layer should come up; you'll die >> later when transport detects a duplicate DECnet node number. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> On 19-May-13 11:01, Robert Jarratt wrote: >>> What is curious now is that I have two instances (identical clones) > running >>> attempting to talk to each other. The first message one sends to the > other >>> crashes the OS: >>> >>> ********** >>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>> *ADDITIONAL DATA: 000000172507, 000000000200 >>> ********** >>> >>> The odd thing is that I have delivered the same data that was sent from > the >>> other end, so it should be valid data. >>> >>> The data is: 05 06 C0 00 00 01 >>> >>> That data does not seem to completely match the DDCMP spec I have, I >> think >>> some checksum is supposed to follow. Is that supposed to be added by the >> KMC >>> perhaps? >>> >>> I don't fully expect it to work because they are clones so would expect >> some >>> kind of error, but would not expect a crash, or am I wrong? >>> >>> Regards >>> >>> Rob >>> >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Robert Jarratt >>>> Sent: 19 May 2013 15:21 >>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>> I have made some progress. I realised that I did not have the interrupt >>>> acknowledgement routines set up in the DIB. It is working a bit better >>> now. >>>> I have indeed seen some commands to read the ram and verify the >>>> microcode, it does all this to check the KMC is working before enabling >>> it. >>>> This particular code has never (as far as I know) worked for the 11 or > the >>>> VAX. I wrote the DMC11 code for those. This code I am working with now >>>> came from someone else and was written for the PDP1) for a much older >>>> version of SIMH. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 14:54 >>>>> To: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>>> I am pretty sure I am doing all the things you mention already >>>>> Then I need a trace of what's happening to the registers, and what > simh >>>>> thinks it's doing with the interrupts. (It would be easiest to > follow >>>>> if you output both octal and decode the register names/fields, though >>>>> I >>>> can >>>>> still think - slowly- in octal.) >>>>> >>>>> Also, I thought this code was working for the -11/VAX. If so, the >>>>> basics >>>> must >>>>> be OK, though the drivers may well take a different approach to the >>>> device. >>>>> Received data should produce either a control-out (error, e.g. no >>>>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. >>>>> The >>>> message >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>> >>>>> Transmit done - also note that we ignore interrupts unless the 'last >>>> buffer' bit >>>>> is set. (The DDCMP header and data are in two BDL segments, and >>>>> require two interrupts.) >>>>> >>>>> Finally, I'm not sure if you'll see it used, but there is code in the >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP 400) >> to >>>>> force the microcontroller to execute several known instructions - to >>>> access its >>>>> data ram, registers & PC. This is primarily used to dump a KMC that >>>>> halts >>>> - it >>>>> doesn't seem to be used when the built-in ucode is loaded. But some >>>>> of these are also used to verify data ram at initialization. Failure >>>>> to >>>> verify will >>>>> cause the device to be disabled. We can go down that path if you see >>>> those >>>>> bits being set in a trace. >>>>> >>>>> Look for KMCXCT calls in >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>> sources/kdpsrv.mac.html >>>>> TOPS-10 doesn't do this. The microinstructions are defined in >>>>> http://bitsavers.trailing- >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>> nual.pdf >>>>> >>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>> 0Manual.pdf> >>>>> The subset is pretty small - load address register, load/store >>>>> indirect >>>> (with >>>>> increment), & branch. I think you ought to be able to crash simh if >>>>> an unknown instruction is forced, including a branch to an address >>>>> other than >>>> 0. >>>>> Ugly device, ugly driver. Sigh. >>>>> >>>>> >>>>> This communication may not represent my employer's views, if any, on >>>>> the matters discussed. >>>>> >>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>> Thanks Timothe, >>>>>> >>>>>> I am pretty sure I am doing all the things you mention already >>>>>> (sorry I didn't make that clear), but I will check through >>>>>> everything you have said, just in case I have missed something. >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >> bounces at trailing- >>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>> Sent: 19 May 2013 11:26 >>>>>>> To: simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> A couple of other things come to mind (naturally, after pushing >>>> 'send'): >>>>>>> Initialization will load/verify the microcode. That has to work. >>>>>>> >>>>>>> After setting RUN and the interrupt enables, expect base-in and >>>>>>> control-in command to establish the DUP CSR address, buffers, line >>>>> mode/enable. >>>>>>> These require that the KMC respond to KMCRQI by initiating an A >>>>>>> vector interrupt. >>>>>>> >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set (BSIO) >>>>>>> and bit >>>>>> clear >>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>> >>>>>>> For better directed hints, I'd need more detail on what is and >>>>>>> isn't >>>>>> happening. >>>>>>> This communication may not represent my employer's views, if any, >>>>>>> on the matters discussed. >>>>>>> >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>> >>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at the >>>>>>>>>> right place to look at TOPS-20 driver code for the KMC11? I can >>>>>>>>>> see that it is trying to get the Microprocessor to do something >>>>>>>>>> and read back some values, but I don't know what values it wants >>>>>>>>>> to get and so it reports: >>>>>>>>> Hi, Rob, >>>>>>>>> >>>>>>>>> http://pdp-10.trailing- >>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>> l >>>>>>>>> >>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>> >>>>>>>>> >>>>>>>>> Rich _______________________________________________ >>>>>>>>> Simh mailing list >>>>>>>>> Simh at trailing-edge.com >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>> I am making some progress with getting the KMC/DUP emulation >>>>> working >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, which >>>>>>>> is the interrupts to tell the OS that the KMC has processed a >>> buffer. >>>>>>>> The OS sets the interrupt enable bit and when I have something to >>>>>>>> report to the OS I set the relevant interrupt bit. However, >>>>>>>> nothing happens when I do that. I am wondering if I have the right >>>>>>>> interrupt bit? I am using bits 8 and 9 (decimal). >>>>>>>> >>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>> >>>>>>>> Can anyone help? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Rob >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Simh mailing list >>>>>>>> Simh at trailing-edge.com >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 16:01:04 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 21:01:04 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <5199054D.2030909@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> Message-ID: <03b401ce54cb$99044050$cb0cc0f0$@ntlworld.com> Thanks! There was a bug in my interrupt acknowledge routine. With that fixed the interrupts now seem to be working OK. I have made progress, with the two clones talking to each other I get this now: ******************** *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 *BAD DDCMP HEADER *ADDITIONAL DATA: 746314746314, 746314777777 ******************** I am going to have to re-learn MACRO to work out why it is failing. The code I see has two jumps to BUMHDR, I can't work out what the first one means, the second seems to be checking the first byte, which being 0x06 should be OK, so it is probably the first condition that is failing. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Timothe Litt > Sent: 19 May 2013 18:01 > To: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > "KMCIII". > > You need to tell simh what vector to use when you tell it about the pending > interrupt. Most devices have only one vector. The KMC (and > DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. > (Or whatever symbol you used.) A should be generated by RDI; B by RDO. > > That will tell simh how to find the right service routine. > > IIRC, if both happen to be pending at the same time, A takes precedence. > > Without seeing the code, I can't be more explicit... > > Oh, be careful when you talk about bit numbers. The unibus is little-endian > (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > This communication may not represent my employer's views, if any, on the > matters discussed. > > On 19-May-13 12:36, Robert Jarratt wrote: > > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > > not an A, so that would make sense. I have A vectored at bit 8, and B at bit > 9. > > > > Are you referring to this code: > > > > ;HERE FOR INPUT INTERRUPTS > > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > MOVEI 17,KMCACS ;BUILD BLT POINTER > > BLT 17,KMCACS+16 ;SAVE REST OF REGS > > MOVE P,[-40,,KMCIPL] ;SET UP STACK > > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > RDIO T2,BSEL2(T4) ;GET RDI FLAG > > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > TRNN T2,KMCRDI ;AND IS IT READY ? > > BUG (KMCIII,<,>) << A interrupt with nothing in the > driver queue, or RDI not set > > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > FLAG << CSR BIT requesting an A interrupt > > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > when driver queue empty > > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > << the command is then removed from the driver queue and written to > > the KMC. The KMC > << must clear RDI until it is ready to take the next command. (Note that > otherwise if the queue depth >1, the << A interrupt will happen > immediately. > > If so, then despite the fact that I am setting bit 9 in the interrupt > > request, it seems to be going to the A interrupt handler. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Timothe Litt > >> Sent: 19 May 2013 17:01 > >> Cc: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > > interrupt. > >> (KMCRDI is 20; RDO is 200) > >> > >> RDYO should always go to IVB; RDYI to IVA. > >> > >> Since we took an IVA interrupt, the driver thinks its trying to give > >> the > > KMC a > >> command, but the interrupt is going to the wrong vector since RDYI is > >> not > > set. > >> So either you're generating an IVA but setting the wrong status bit, > >> or generating an Ivb event but not to the right vector. Or perhaps > >> you have > > an > >> overrun - the interrupt has to be cleared when the drive clears the > >> RDx > > bit. > >> The data looks like a DDCMP start, less the CRCs. That indicates > >> that a > > fair bit > >> of stuff is working; this is the data that the -10 provides to the KMC. > >> > >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header and > >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >> CRC errors are reported by control out bits. Since the KMC both adds > >> on transmit and removes/checks on receive, and you are running over > >> an error- checked transport, you can get away with not simulating > >> this - unless you want to interoperate with an interface that does add the > CRCs. > >> > >> Even if the systems are cloned, the DDCMP layer should come up; > >> you'll die later when transport detects a duplicate DECnet node number. > >> > >> > >> This communication may not represent my employer's views, if any, on > >> the matters discussed. > >> > >> On 19-May-13 11:01, Robert Jarratt wrote: > >>> What is curious now is that I have two instances (identical clones) > > running > >>> attempting to talk to each other. The first message one sends to the > > other > >>> crashes the OS: > >>> > >>> ********** > >>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>> ********** > >>> > >>> The odd thing is that I have delivered the same data that was sent > >>> from > > the > >>> other end, so it should be valid data. > >>> > >>> The data is: 05 06 C0 00 00 01 > >>> > >>> That data does not seem to completely match the DDCMP spec I have, I > >> think > >>> some checksum is supposed to follow. Is that supposed to be added by > >>> the > >> KMC > >>> perhaps? > >>> > >>> I don't fully expect it to work because they are clones so would > >>> expect > >> some > >>> kind of error, but would not expect a crash, or am I wrong? > >>> > >>> Regards > >>> > >>> Rob > >>> > >>>> -----Original Message----- > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>> edge.com] On Behalf Of Robert Jarratt > >>>> Sent: 19 May 2013 15:21 > >>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>> > >>>> I have made some progress. I realised that I did not have the > >>>> interrupt acknowledgement routines set up in the DIB. It is working > >>>> a bit better > >>> now. > >>>> I have indeed seen some commands to read the ram and verify the > >>>> microcode, it does all this to check the KMC is working before > >>>> enabling > >>> it. > >>>> This particular code has never (as far as I know) worked for the 11 > >>>> or > > the > >>>> VAX. I wrote the DMC11 code for those. This code I am working with > >>>> now came from someone else and was written for the PDP1) for a > much > >>>> older version of SIMH. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com > >>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 14:54 > >>>>> To: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>>> I am pretty sure I am doing all the things you mention already > >>>>> Then I need a trace of what's happening to the registers, and what > > simh > >>>>> thinks it's doing with the interrupts. (It would be easiest to > > follow > >>>>> if you output both octal and decode the register names/fields, > >>>>> though I > >>>> can > >>>>> still think - slowly- in octal.) > >>>>> > >>>>> Also, I thought this code was working for the -11/VAX. If so, the > >>>>> basics > >>>> must > >>>>> be OK, though the drivers may well take a different approach to > >>>>> the > >>>> device. > >>>>> Received data should produce either a control-out (error, e.g. no > >>>>> buffer available or DSR change or NXM...) or a buffer-out B interrupt. > >>>>> The > >>>> message > >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>> > >>>>> Transmit done - also note that we ignore interrupts unless the > >>>>> 'last > >>>> buffer' bit > >>>>> is set. (The DDCMP header and data are in two BDL segments, and > >>>>> require two interrupts.) > >>>>> > >>>>> Finally, I'm not sure if you'll see it used, but there is code in > >>>>> the > >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP > >>>>> 400) > >> to > >>>>> force the microcontroller to execute several known instructions - > >>>>> to > >>>> access its > >>>>> data ram, registers & PC. This is primarily used to dump a KMC > >>>>> that halts > >>>> - it > >>>>> doesn't seem to be used when the built-in ucode is loaded. But > >>>>> some of these are also used to verify data ram at initialization. > >>>>> Failure to > >>>> verify will > >>>>> cause the device to be disabled. We can go down that path if you > >>>>> see > >>>> those > >>>>> bits being set in a trace. > >>>>> > >>>>> Look for KMCXCT calls in > >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>> sources/kdpsrv.mac.html > >>>>> TOPS-10 doesn't do this. The microinstructions are defined in > >>>>> http://bitsavers.trailing- > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>> nual.pdf > >>>>> >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > >>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>> 0Manual.pdf> > >>>>> The subset is pretty small - load address register, load/store > >>>>> indirect > >>>> (with > >>>>> increment), & branch. I think you ought to be able to crash simh > >>>>> if an unknown instruction is forced, including a branch to an > >>>>> address other than > >>>> 0. > >>>>> Ugly device, ugly driver. Sigh. > >>>>> > >>>>> > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>> Thanks Timothe, > >>>>>> > >>>>>> I am pretty sure I am doing all the things you mention already > >>>>>> (sorry I didn't make that clear), but I will check through > >>>>>> everything you have said, just in case I have missed something. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>> Sent: 19 May 2013 11:26 > >>>>>>> To: simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>> A couple of other things come to mind (naturally, after pushing > >>>> 'send'): > >>>>>>> Initialization will load/verify the microcode. That has to work. > >>>>>>> > >>>>>>> After setting RUN and the interrupt enables, expect base-in and > >>>>>>> control-in command to establish the DUP CSR address, buffers, > >>>>>>> line > >>>>> mode/enable. > >>>>>>> These require that the KMC respond to KMCRQI by initiating an A > >>>>>>> vector interrupt. > >>>>>>> > >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>> (BSIO) and bit > >>>>>> clear > >>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>> > >>>>>>> For better directed hints, I'd need more detail on what is and > >>>>>>> isn't > >>>>>> happening. > >>>>>>> This communication may not represent my employer's views, if > >>>>>>> any, on the matters discussed. > >>>>>>> > >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>> bounces at trailing- > >>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>> > >>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at > >>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? > >>>>>>>>>> I can see that it is trying to get the Microprocessor to do > >>>>>>>>>> something and read back some values, but I don't know what > >>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>> Hi, Rob, > >>>>>>>>> > >>>>>>>>> http://pdp-10.trailing- > >>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>> l > >>>>>>>>> > >>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Rich > _______________________________________________ > >>>>>>>>> Simh mailing list > >>>>>>>>> Simh at trailing-edge.com > >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>> I am making some progress with getting the KMC/DUP emulation > >>>>> working > >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > >>>>>>>> which is the interrupts to tell the OS that the KMC has > >>>>>>>> processed a > >>> buffer. > >>>>>>>> The OS sets the interrupt enable bit and when I have something > >>>>>>>> to report to the OS I set the relevant interrupt bit. However, > >>>>>>>> nothing happens when I do that. I am wondering if I have the > >>>>>>>> right interrupt bit? I am using bits 8 and 9 (decimal). > >>>>>>>> > >>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>> > >>>>>>>> Can anyone help? > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> Rob > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Simh mailing list > >>>>>>>> Simh at trailing-edge.com > >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>> _______________________________________________ > >>>> Simh mailing list > >>>> Simh at trailing-edge.com > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 19 16:06:15 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 21:06:15 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> Message-ID: <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> Oops, meant to say the first byte sent is 0x05. > -----Original Message----- > From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > Sent: 19 May 2013 21:01 > To: 'Timothe Litt'; 'simh at trailing-edge.com' > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Thanks! There was a bug in my interrupt acknowledge routine. With that > fixed the interrupts now seem to be working OK. I have made progress, with > the two clones talking to each other I get this now: > > > ******************** > *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > *BAD DDCMP HEADER > *ADDITIONAL DATA: 746314746314, 746314777777 > ******************** > > I am going to have to re-learn MACRO to work out why it is failing. The code I > see has two jumps to BUMHDR, I can't work out what the first one means, > the second seems to be checking the first byte, which being 0x06 should be > OK, so it is probably the first condition that is failing. > > Regards > > Rob > > > > -----Original Message----- > > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > edge.com] On Behalf Of Timothe Litt > > Sent: 19 May 2013 18:01 > > To: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > > "KMCIII". > > > > You need to tell simh what vector to use when you tell it about the > > pending interrupt. Most devices have only one vector. The KMC (and > > DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > > the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > > VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. > > (Or whatever symbol you used.) A should be generated by RDI; B by RDO. > > > > That will tell simh how to find the right service routine. > > > > IIRC, if both happen to be pending at the same time, A takes precedence. > > > > Without seeing the code, I can't be more explicit... > > > > Oh, be careful when you talk about bit numbers. The unibus is > > little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 12:36, Robert Jarratt wrote: > > > Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > > > not an A, so that would make sense. I have A vectored at bit 8, and > > > B at bit > > 9. > > > > > > Are you referring to this code: > > > > > > ;HERE FOR INPUT INTERRUPTS > > > KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > > MOVEI 17,KMCACS ;BUILD BLT POINTER > > > BLT 17,KMCACS+16 ;SAVE REST OF REGS > > > MOVE P,[-40,,KMCIPL] ;SET UP STACK > > > MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > > RDIO T2,BSEL2(T4) ;GET RDI FLAG > > > MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > > CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > > TRNN T2,KMCRDI ;AND IS IT READY ? > > > BUG (KMCIII,<,>) << A interrupt with nothing in the > > driver queue, or RDI not set > > > CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > > MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > > ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > > MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > > MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > > FLAG << CSR BIT requesting an A interrupt > > > CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > > BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > > when driver queue empty > > > MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > > MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > > << the command is then removed from the driver queue and written to > > > the KMC. The KMC > > << must clear RDI until it is ready to take the next command. (Note > > that otherwise if the queue depth >1, the << A interrupt will happen > > immediately. > > > If so, then despite the fact that I am setting bit 9 in the > > > interrupt request, it seems to be going to the A interrupt handler. > > > > > > Regards > > > > > > Rob > > > > > >> -----Original Message----- > > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > > >> edge.com] On Behalf Of Timothe Litt > > >> Sent: 19 May 2013 17:01 > > >> Cc: simh at trailing-edge.com > > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> The bugcheck is saying that the RDYO is set, but not RDYI on an A > > > interrupt. > > >> (KMCRDI is 20; RDO is 200) > > >> > > >> RDYO should always go to IVB; RDYI to IVA. > > >> > > >> Since we took an IVA interrupt, the driver thinks its trying to > > >> give the > > > KMC a > > >> command, but the interrupt is going to the wrong vector since RDYI > > >> is not > > > set. > > >> So either you're generating an IVA but setting the wrong status > > >> bit, or generating an Ivb event but not to the right vector. Or > > >> perhaps you have > > > an > > >> overrun - the interrupt has to be cleared when the drive clears the > > >> RDx > > > bit. > > >> The data looks like a DDCMP start, less the CRCs. That indicates > > >> that a > > > fair bit > > >> of stuff is working; this is the data that the -10 provides to the KMC. > > >> > > >> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > > >> and > > >> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > > >> CRC errors are reported by control out bits. Since the KMC both > > >> adds on transmit and removes/checks on receive, and you are running > > >> over an error- checked transport, you can get away with not > > >> simulating this - unless you want to interoperate with an interface > > >> that does add the > > CRCs. > > >> > > >> Even if the systems are cloned, the DDCMP layer should come up; > > >> you'll die later when transport detects a duplicate DECnet node number. > > >> > > >> > > >> This communication may not represent my employer's views, if any, > > >> on the matters discussed. > > >> > > >> On 19-May-13 11:01, Robert Jarratt wrote: > > >>> What is curious now is that I have two instances (identical > > >>> clones) > > > running > > >>> attempting to talk to each other. The first message one sends to > > >>> the > > > other > > >>> crashes the OS: > > >>> > > >>> ********** > > >>> *BUGHLT "KMCIII" AT 19-May-2013 15: > > >>> *ADDITIONAL DATA: 000000172507, 000000000200 > > >>> ********** > > >>> > > >>> The odd thing is that I have delivered the same data that was sent > > >>> from > > > the > > >>> other end, so it should be valid data. > > >>> > > >>> The data is: 05 06 C0 00 00 01 > > >>> > > >>> That data does not seem to completely match the DDCMP spec I have, > > >>> I > > >> think > > >>> some checksum is supposed to follow. Is that supposed to be added > > >>> by the > > >> KMC > > >>> perhaps? > > >>> > > >>> I don't fully expect it to work because they are clones so would > > >>> expect > > >> some > > >>> kind of error, but would not expect a crash, or am I wrong? > > >>> > > >>> Regards > > >>> > > >>> Rob > > >>> > > >>>> -----Original Message----- > > >>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>> edge.com] On Behalf Of Robert Jarratt > > >>>> Sent: 19 May 2013 15:21 > > >>>> To: 'Timothe Litt'; simh at trailing-edge.com > > >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>> > > >>>> I have made some progress. I realised that I did not have the > > >>>> interrupt acknowledgement routines set up in the DIB. It is > > >>>> working a bit better > > >>> now. > > >>>> I have indeed seen some commands to read the ram and verify the > > >>>> microcode, it does all this to check the KMC is working before > > >>>> enabling > > >>> it. > > >>>> This particular code has never (as far as I know) worked for the > > >>>> 11 or > > > the > > >>>> VAX. I wrote the DMC11 code for those. This code I am working > > >>>> with now came from someone else and was written for the PDP1) for > > >>>> a > > much > > >>>> older version of SIMH. > > >>>> > > >>>> Regards > > >>>> > > >>>> Rob > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: simh-bounces at trailing-edge.com > > >>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe > > >>>>> Litt > > >>>>> Sent: 19 May 2013 14:54 > > >>>>> To: simh at trailing-edge.com > > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>> Then I need a trace of what's happening to the registers, and > > >>>>> what > > > simh > > >>>>> thinks it's doing with the interrupts. (It would be easiest to > > > follow > > >>>>> if you output both octal and decode the register names/fields, > > >>>>> though I > > >>>> can > > >>>>> still think - slowly- in octal.) > > >>>>> > > >>>>> Also, I thought this code was working for the -11/VAX. If so, > > >>>>> the basics > > >>>> must > > >>>>> be OK, though the drivers may well take a different approach to > > >>>>> the > > >>>> device. > > >>>>> Received data should produce either a control-out (error, e.g. > > >>>>> no buffer available or DSR change or NXM...) or a buffer-out B > interrupt. > > >>>>> The > > >>>> message > > >>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > > >>>>> > > >>>>> Transmit done - also note that we ignore interrupts unless the > > >>>>> 'last > > >>>> buffer' bit > > >>>>> is set. (The DDCMP header and data are in two BDL segments, and > > >>>>> require two interrupts.) > > >>>>> > > >>>>> Finally, I'm not sure if you'll see it used, but there is code > > >>>>> in the > > >>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP > > >>>>> 400) > > >> to > > >>>>> force the microcontroller to execute several known instructions > > >>>>> - to > > >>>> access its > > >>>>> data ram, registers & PC. This is primarily used to dump a KMC > > >>>>> that halts > > >>>> - it > > >>>>> doesn't seem to be used when the built-in ucode is loaded. But > > >>>>> some of these are also used to verify data ram at initialization. > > >>>>> Failure to > > >>>> verify will > > >>>>> cause the device to be disabled. We can go down that path if > > >>>>> you see > > >>>> those > > >>>>> bits being set in a trace. > > >>>>> > > >>>>> Look for KMCXCT calls in > > >>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > >>>>> sources/kdpsrv.mac.html > > >>>>> TOPS-10 doesn't do this. The microinstructions are defined in > > >>>>> http://bitsavers.trailing- > > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > >>>>> nual.pdf > > >>>>> > >>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- > > >>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > >>>>> 0Manual.pdf> > > >>>>> The subset is pretty small - load address register, load/store > > >>>>> indirect > > >>>> (with > > >>>>> increment), & branch. I think you ought to be able to crash > > >>>>> simh if an unknown instruction is forced, including a branch to > > >>>>> an address other than > > >>>> 0. > > >>>>> Ugly device, ugly driver. Sigh. > > >>>>> > > >>>>> > > >>>>> This communication may not represent my employer's views, if > > >>>>> any, on the matters discussed. > > >>>>> > > >>>>> On 19-May-13 07:42, Robert Jarratt wrote: > > >>>>>> Thanks Timothe, > > >>>>>> > > >>>>>> I am pretty sure I am doing all the things you mention already > > >>>>>> (sorry I didn't make that clear), but I will check through > > >>>>>> everything you have said, just in case I have missed something. > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >> bounces at trailing- > > >>>>>>> edge.com] On Behalf Of Timothe Litt > > >>>>>>> Sent: 19 May 2013 11:26 > > >>>>>>> To: simh at trailing-edge.com > > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>> > > >>>>>>> A couple of other things come to mind (naturally, after > > >>>>>>> pushing > > >>>> 'send'): > > >>>>>>> Initialization will load/verify the microcode. That has to work. > > >>>>>>> > > >>>>>>> After setting RUN and the interrupt enables, expect base-in > > >>>>>>> and control-in command to establish the DUP CSR address, > > >>>>>>> buffers, line > > >>>>> mode/enable. > > >>>>>>> These require that the KMC respond to KMCRQI by initiating an > > >>>>>>> A vector interrupt. > > >>>>>>> > > >>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > > >>>>>>> (BSIO) and bit > > >>>>>> clear > > >>>>>>> (BCIO) instructions that also touch the KMC. > > >>>>>>> > > >>>>>>> For better directed hints, I'd need more detail on what is and > > >>>>>>> isn't > > >>>>>> happening. > > >>>>>>> This communication may not represent my employer's views, if > > >>>>>>> any, on the matters discussed. > > >>>>>>> > > >>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>>>>>>> -----Original Message----- > > >>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>> bounces at trailing- > > >>>>>>>>> edge.com] On Behalf Of Rich Alderson > > >>>>>>>>> Sent: 08 May 2013 01:02 > > >>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>>> > > >>>>>>>>>> From: "Robert Jarratt" > > >>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at > > >>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? > > >>>>>>>>>> I can see that it is trying to get the Microprocessor to do > > >>>>>>>>>> something and read back some values, but I don't know what > > >>>>>>>>>> values it wants to get and so it reports: > > >>>>>>>>> Hi, Rob, > > >>>>>>>>> > > >>>>>>>>> http://pdp-10.trailing- > > >>>>> edge.com/tops20v41_monitor_sources/index.htm > > >>>>>>>>> l > > >>>>>>>>> > > >>>>>>>>> You want the file KDPSRV.MAC in that directory. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Rich > > _______________________________________________ > > >>>>>>>>> Simh mailing list > > >>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>>> I am making some progress with getting the KMC/DUP > emulation > > >>>>> working > > >>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > > >>>>>>>> which is the interrupts to tell the OS that the KMC has > > >>>>>>>> processed a > > >>> buffer. > > >>>>>>>> The OS sets the interrupt enable bit and when I have > > >>>>>>>> something to report to the OS I set the relevant interrupt > > >>>>>>>> bit. However, nothing happens when I do that. I am wondering > > >>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 (decimal). > > >>>>>>>> > > >>>>>>>> I am not sure how to find out which bit I should be setting. > > >>>>>>>> > > >>>>>>>> Can anyone help? > > >>>>>>>> > > >>>>>>>> Regards > > >>>>>>>> > > >>>>>>>> Rob > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> Simh mailing list > > >>>>>>>> Simh at trailing-edge.com > > >>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>> _______________________________________________ > > >>>> Simh mailing list > > >>>> Simh at trailing-edge.com > > >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > From litt at ieee.org Sun May 19 16:40:57 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 19 May 2013 16:40:57 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> Message-ID: <519938D9.1010209@ieee.org> This is progress. Looks to me like the data isn't being stored properly. The ADDITIONAL DATA is the first 8 bytes of the data buffer. The SKIPL says the sign bit is set (which it is in 7463...). That's not possible. So I suspect you're not writing the data thru the UBA map correctly. Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit words packed into 18-bit 1/2 words. This looks like: /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE / /-- The ENQ goes here / / -- The START goes here ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 Since 00 is constant, the first digit can't be > 1. 7 mumble is. Thus for 05 06 (ENQ START), we should see something like 3005,,... in the first word. (5 + 6 << 8) Also, you need to map the UBA address to PDP-10 memory (which you seem to be doing for reads). This communication may not represent my employer's views, if any, on the matters discussed. On 19-May-13 16:06, Robert Jarratt wrote: > Oops, meant to say the first byte sent is 0x05. > >> -----Original Message----- >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >> Sent: 19 May 2013 21:01 >> To: 'Timothe Litt'; 'simh at trailing-edge.com' >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> Thanks! There was a bug in my interrupt acknowledge routine. With that >> fixed the interrupts now seem to be working OK. I have made progress, with >> the two clones talking to each other I get this now: >> >> >> ******************** >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >> *BAD DDCMP HEADER >> *ADDITIONAL DATA: 746314746314, 746314777777 >> ******************** >> >> I am going to have to re-learn MACRO to work out why it is failing. The > code I >> see has two jumps to BUMHDR, I can't work out what the first one means, >> the second seems to be checking the first byte, which being 0x06 should be >> OK, so it is probably the first condition that is failing. >> >> Regards >> >> Rob >> >> >>> -----Original Message----- >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>> edge.com] On Behalf Of Timothe Litt >>> Sent: 19 May 2013 18:01 >>> To: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT >>> "KMCIII". >>> >>> You need to tell simh what vector to use when you tell it about the >>> pending interrupt. Most devices have only one vector. The KMC (and >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So in >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber or >>> VEC_KDP * kmcnumber +4, depending on which interrupt is being granted. >>> (Or whatever symbol you used.) A should be generated by RDI; B by RDO. >>> >>> That will tell simh how to find the right service routine. >>> >>> IIRC, if both happen to be pending at the same time, A takes precedence. >>> >>> Without seeing the code, I can't be more explicit... >>> >>> Oh, be careful when you talk about bit numbers. The unibus is >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 12:36, Robert Jarratt wrote: >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, >>>> not an A, so that would make sense. I have A vectored at bit 8, and >>>> B at bit >>> 9. >>>> Are you referring to this code: >>>> >>>> ;HERE FOR INPUT INTERRUPTS >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? >>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the >>> driver queue, or RDI not set >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT >>> FLAG << CSR BIT requesting an A interrupt >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request >>> when driver queue empty >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY >>>> << the command is then removed from the driver queue and written to >>>> the KMC. The KMC >>> << must clear RDI until it is ready to take the next command. (Note >>> that otherwise if the queue depth >1, the << A interrupt will happen >>> immediately. >>>> If so, then despite the fact that I am setting bit 9 in the >>>> interrupt request, it seems to be going to the A interrupt handler. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>>> edge.com] On Behalf Of Timothe Litt >>>>> Sent: 19 May 2013 17:01 >>>>> Cc: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an A >>>> interrupt. >>>>> (KMCRDI is 20; RDO is 200) >>>>> >>>>> RDYO should always go to IVB; RDYI to IVA. >>>>> >>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>> give the >>>> KMC a >>>>> command, but the interrupt is going to the wrong vector since RDYI >>>>> is not >>>> set. >>>>> So either you're generating an IVA but setting the wrong status >>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>> perhaps you have >>>> an >>>>> overrun - the interrupt has to be cleared when the drive clears the >>>>> RDx >>>> bit. >>>>> The data looks like a DDCMP start, less the CRCs. That indicates >>>>> that a >>>> fair bit >>>>> of stuff is working; this is the data that the -10 provides to the > KMC. >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header >>>>> and >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >>>>> CRC errors are reported by control out bits. Since the KMC both >>>>> adds on transmit and removes/checks on receive, and you are running >>>>> over an error- checked transport, you can get away with not >>>>> simulating this - unless you want to interoperate with an interface >>>>> that does add the >>> CRCs. >>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>> you'll die later when transport detects a duplicate DECnet node > number. >>>>> >>>>> This communication may not represent my employer's views, if any, >>>>> on the matters discussed. >>>>> >>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>> What is curious now is that I have two instances (identical >>>>>> clones) >>>> running >>>>>> attempting to talk to each other. The first message one sends to >>>>>> the >>>> other >>>>>> crashes the OS: >>>>>> >>>>>> ********** >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>> ********** >>>>>> >>>>>> The odd thing is that I have delivered the same data that was sent >>>>>> from >>>> the >>>>>> other end, so it should be valid data. >>>>>> >>>>>> The data is: 05 06 C0 00 00 01 >>>>>> >>>>>> That data does not seem to completely match the DDCMP spec I have, >>>>>> I >>>>> think >>>>>> some checksum is supposed to follow. Is that supposed to be added >>>>>> by the >>>>> KMC >>>>>> perhaps? >>>>>> >>>>>> I don't fully expect it to work because they are clones so would >>>>>> expect >>>>> some >>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>> >>>>>> Regards >>>>>> >>>>>> Rob >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>> Sent: 19 May 2013 15:21 >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> I have made some progress. I realised that I did not have the >>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>> working a bit better >>>>>> now. >>>>>>> I have indeed seen some commands to read the ram and verify the >>>>>>> microcode, it does all this to check the KMC is working before >>>>>>> enabling >>>>>> it. >>>>>>> This particular code has never (as far as I know) worked for the >>>>>>> 11 or >>>> the >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>> with now came from someone else and was written for the PDP1) for >>>>>>> a >>> much >>>>>>> older version of SIMH. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe >>>>>>>> Litt >>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>> To: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>>> I am pretty sure I am doing all the things you mention already >>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>> what >>>> simh >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to >>>> follow >>>>>>>> if you output both octal and decode the register names/fields, >>>>>>>> though I >>>>>>> can >>>>>>>> still think - slowly- in octal.) >>>>>>>> >>>>>>>> Also, I thought this code was working for the -11/VAX. If so, >>>>>>>> the basics >>>>>>> must >>>>>>>> be OK, though the drivers may well take a different approach to >>>>>>>> the >>>>>>> device. >>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out B >> interrupt. >>>>>>>> The >>>>>>> message >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>> >>>>>>>> Transmit done - also note that we ignore interrupts unless the >>>>>>>> 'last >>>>>>> buffer' bit >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, and >>>>>>>> require two interrupts.) >>>>>>>> >>>>>>>> Finally, I'm not sure if you'll see it used, but there is code >>>>>>>> in the >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step (KMCSUP >>>>>>>> 400) >>>>> to >>>>>>>> force the microcontroller to execute several known instructions >>>>>>>> - to >>>>>>> access its >>>>>>>> data ram, registers & PC. This is primarily used to dump a KMC >>>>>>>> that halts >>>>>>> - it >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. But >>>>>>>> some of these are also used to verify data ram at initialization. >>>>>>>> Failure to >>>>>>> verify will >>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>> you see >>>>>>> those >>>>>>>> bits being set in a trace. >>>>>>>> >>>>>>>> Look for KMCXCT calls in >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>> sources/kdpsrv.mac.html >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined in >>>>>>>> http://bitsavers.trailing- >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>> nual.pdf >>>>>>>> >>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11-OP- >>>>>>>> >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>> 0Manual.pdf> >>>>>>>> The subset is pretty small - load address register, load/store >>>>>>>> indirect >>>>>>> (with >>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>> simh if an unknown instruction is forced, including a branch to >>>>>>>> an address other than >>>>>>> 0. >>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>> >>>>>>>> >>>>>>>> This communication may not represent my employer's views, if >>>>>>>> any, on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>> Thanks Timothe, >>>>>>>>> >>>>>>>>> I am pretty sure I am doing all the things you mention already >>>>>>>>> (sorry I didn't make that clear), but I will check through >>>>>>>>> everything you have said, just in case I have missed something. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>> pushing >>>>>>> 'send'): >>>>>>>>>> Initialization will load/verify the microcode. That has to > work. >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in >>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>> buffers, line >>>>>>>> mode/enable. >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating an >>>>>>>>>> A vector interrupt. >>>>>>>>>> >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>> (BSIO) and bit >>>>>>>>> clear >>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>> >>>>>>>>>> For better directed hints, I'd need more detail on what is and >>>>>>>>>> isn't >>>>>>>>> happening. >>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>> any, on the matters discussed. >>>>>>>>>> >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>> >>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me at >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the KMC11? >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to do >>>>>>>>>>>>> something and read back some values, but I don't know what >>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>> >>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>> l >>>>>>>>>>>> >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Rich >>> _______________________________________________ >>>>>>>>>>>> Simh mailing list >>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>> I am making some progress with getting the KMC/DUP >> emulation >>>>>>>> working >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, >>>>>>>>>>> which is the interrupts to tell the OS that the KMC has >>>>>>>>>>> processed a >>>>>> buffer. >>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>> bit. However, nothing happens when I do that. I am wondering >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > (decimal). >>>>>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>>>>> >>>>>>>>>>> Can anyone help? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Rob >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Simh mailing list >>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>> _______________________________________________ >>>>>>> Simh mailing list >>>>>>> Simh at trailing-edge.com >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Sun May 19 17:46:44 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 19 May 2013 22:46:44 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <519938D9.1010209@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> Message-ID: <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> Thanks, that sounds likely, I will check how I am writing to memory. Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 19 May 2013 21:41 > To: Robert Jarratt > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > This is progress. Looks to me like the data isn't being stored properly. > > The ADDITIONAL DATA is the first 8 bytes of the data buffer. The SKIPL > says the sign bit is set (which it is in 7463...). > That's not possible. > > So I suspect you're not writing the data thru the UBA map correctly. > > Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > words packed into 18-bit 1/2 words. > This looks like: > > /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > / /-- The ENQ goes here > / / -- The START goes here > ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 > ! 00 ! byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > > Since 00 is constant, the first digit can't be > 1. 7 mumble is. > > Thus for 05 06 (ENQ START), we should see something like 3005,,... in > the first word. > (5 + 6 << 8) > > Also, you need to map the UBA address to PDP-10 memory (which you seem > to be doing for reads). > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 19-May-13 16:06, Robert Jarratt wrote: > > Oops, meant to say the first byte sent is 0x05. > > > >> -----Original Message----- > >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > >> Sent: 19 May 2013 21:01 > >> To: 'Timothe Litt'; 'simh at trailing-edge.com' > >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> Thanks! There was a bug in my interrupt acknowledge routine. With that > >> fixed the interrupts now seem to be working OK. I have made progress, > with > >> the two clones talking to each other I get this now: > >> > >> > >> ******************** > >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > >> *BAD DDCMP HEADER > >> *ADDITIONAL DATA: 746314746314, 746314777777 > >> ******************** > >> > >> I am going to have to re-learn MACRO to work out why it is failing. The > > code I > >> see has two jumps to BUMHDR, I can't work out what the first one means, > >> the second seems to be checking the first byte, which being 0x06 should > be > >> OK, so it is probably the first condition that is failing. > >> > >> Regards > >> > >> Rob > >> > >> > >>> -----Original Message----- > >>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >>> edge.com] On Behalf Of Timothe Litt > >>> Sent: 19 May 2013 18:01 > >>> To: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > >>> "KMCIII". > >>> > >>> You need to tell simh what vector to use when you tell it about the > >>> pending interrupt. Most devices have only one vector. The KMC (and > >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So in > >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber or > >>> VEC_KDP * kmcnumber +4, depending on which interrupt is being > granted. > >>> (Or whatever symbol you used.) A should be generated by RDI; B by > RDO. > >>> > >>> That will tell simh how to find the right service routine. > >>> > >>> IIRC, if both happen to be pending at the same time, A takes > precedence. > >>> > >>> Without seeing the code, I can't be more explicit... > >>> > >>> Oh, be careful when you talk about bit numbers. The unibus is > >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 12:36, Robert Jarratt wrote: > >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B interrupt, > >>>> not an A, so that would make sense. I have A vectored at bit 8, and > >>>> B at bit > >>> 9. > >>>> Are you referring to this code: > >>>> > >>>> ;HERE FOR INPUT INTERRUPTS > >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > >>>> TRNN T2,KMCRDI ;AND IS IT READY ? > >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the > >>> driver queue, or RDI not set > >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > >>> FLAG << CSR BIT requesting an A interrupt > >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > >>> when driver queue empty > >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > >>>> << the command is then removed from the driver queue and written > to > >>>> the KMC. The KMC > >>> << must clear RDI until it is ready to take the next command. (Note > >>> that otherwise if the queue depth >1, the << A interrupt will happen > >>> immediately. > >>>> If so, then despite the fact that I am setting bit 9 in the > >>>> interrupt request, it seems to be going to the A interrupt handler. > >>>> > >>>> Regards > >>>> > >>>> Rob > >>>> > >>>>> -----Original Message----- > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > bounces at trailing- > >>>>> edge.com] On Behalf Of Timothe Litt > >>>>> Sent: 19 May 2013 17:01 > >>>>> Cc: simh at trailing-edge.com > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an A > >>>> interrupt. > >>>>> (KMCRDI is 20; RDO is 200) > >>>>> > >>>>> RDYO should always go to IVB; RDYI to IVA. > >>>>> > >>>>> Since we took an IVA interrupt, the driver thinks its trying to > >>>>> give the > >>>> KMC a > >>>>> command, but the interrupt is going to the wrong vector since RDYI > >>>>> is not > >>>> set. > >>>>> So either you're generating an IVA but setting the wrong status > >>>>> bit, or generating an Ivb event but not to the right vector. Or > >>>>> perhaps you have > >>>> an > >>>>> overrun - the interrupt has to be cleared when the drive clears the > >>>>> RDx > >>>> bit. > >>>>> The data looks like a DDCMP start, less the CRCs. That indicates > >>>>> that a > >>>> fair bit > >>>>> of stuff is working; this is the data that the -10 provides to the > > KMC. > >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > >>>>> and > >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >>>>> CRC errors are reported by control out bits. Since the KMC both > >>>>> adds on transmit and removes/checks on receive, and you are > running > >>>>> over an error- checked transport, you can get away with not > >>>>> simulating this - unless you want to interoperate with an interface > >>>>> that does add the > >>> CRCs. > >>>>> Even if the systems are cloned, the DDCMP layer should come up; > >>>>> you'll die later when transport detects a duplicate DECnet node > > number. > >>>>> > >>>>> This communication may not represent my employer's views, if any, > >>>>> on the matters discussed. > >>>>> > >>>>> On 19-May-13 11:01, Robert Jarratt wrote: > >>>>>> What is curious now is that I have two instances (identical > >>>>>> clones) > >>>> running > >>>>>> attempting to talk to each other. The first message one sends to > >>>>>> the > >>>> other > >>>>>> crashes the OS: > >>>>>> > >>>>>> ********** > >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>>>>> ********** > >>>>>> > >>>>>> The odd thing is that I have delivered the same data that was sent > >>>>>> from > >>>> the > >>>>>> other end, so it should be valid data. > >>>>>> > >>>>>> The data is: 05 06 C0 00 00 01 > >>>>>> > >>>>>> That data does not seem to completely match the DDCMP spec I > have, > >>>>>> I > >>>>> think > >>>>>> some checksum is supposed to follow. Is that supposed to be added > >>>>>> by the > >>>>> KMC > >>>>>> perhaps? > >>>>>> > >>>>>> I don't fully expect it to work because they are clones so would > >>>>>> expect > >>>>> some > >>>>>> kind of error, but would not expect a crash, or am I wrong? > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Rob > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>> edge.com] On Behalf Of Robert Jarratt > >>>>>>> Sent: 19 May 2013 15:21 > >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>> > >>>>>>> I have made some progress. I realised that I did not have the > >>>>>>> interrupt acknowledgement routines set up in the DIB. It is > >>>>>>> working a bit better > >>>>>> now. > >>>>>>> I have indeed seen some commands to read the ram and verify the > >>>>>>> microcode, it does all this to check the KMC is working before > >>>>>>> enabling > >>>>>> it. > >>>>>>> This particular code has never (as far as I know) worked for the > >>>>>>> 11 or > >>>> the > >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > >>>>>>> with now came from someone else and was written for the PDP1) > for > >>>>>>> a > >>> much > >>>>>>> older version of SIMH. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Rob > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: simh-bounces at trailing-edge.com > >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe > >>>>>>>> Litt > >>>>>>>> Sent: 19 May 2013 14:54 > >>>>>>>> To: simh at trailing-edge.com > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>> > >>>>>>>>> I am pretty sure I am doing all the things you mention already > >>>>>>>> Then I need a trace of what's happening to the registers, and > >>>>>>>> what > >>>> simh > >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to > >>>> follow > >>>>>>>> if you output both octal and decode the register names/fields, > >>>>>>>> though I > >>>>>>> can > >>>>>>>> still think - slowly- in octal.) > >>>>>>>> > >>>>>>>> Also, I thought this code was working for the -11/VAX. If so, > >>>>>>>> the basics > >>>>>>> must > >>>>>>>> be OK, though the drivers may well take a different approach to > >>>>>>>> the > >>>>>>> device. > >>>>>>>> Received data should produce either a control-out (error, e.g. > >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out B > >> interrupt. > >>>>>>>> The > >>>>>>> message > >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>>>>> > >>>>>>>> Transmit done - also note that we ignore interrupts unless the > >>>>>>>> 'last > >>>>>>> buffer' bit > >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, and > >>>>>>>> require two interrupts.) > >>>>>>>> > >>>>>>>> Finally, I'm not sure if you'll see it used, but there is code > >>>>>>>> in the > >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > (KMCSUP > >>>>>>>> 400) > >>>>> to > >>>>>>>> force the microcontroller to execute several known instructions > >>>>>>>> - to > >>>>>>> access its > >>>>>>>> data ram, registers & PC. This is primarily used to dump a KMC > >>>>>>>> that halts > >>>>>>> - it > >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. But > >>>>>>>> some of these are also used to verify data ram at initialization. > >>>>>>>> Failure to > >>>>>>> verify will > >>>>>>>> cause the device to be disabled. We can go down that path if > >>>>>>>> you see > >>>>>>> those > >>>>>>>> bits being set in a trace. > >>>>>>>> > >>>>>>>> Look for KMCXCT calls in > >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>>>>> sources/kdpsrv.mac.html > >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined in > >>>>>>>> http://bitsavers.trailing- > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > OP- > >>>>>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>>>>> nual.pdf > >>>>>>>> >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > OP- > >>>>>>>> > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>>>>> 0Manual.pdf> > >>>>>>>> The subset is pretty small - load address register, load/store > >>>>>>>> indirect > >>>>>>> (with > >>>>>>>> increment), & branch. I think you ought to be able to crash > >>>>>>>> simh if an unknown instruction is forced, including a branch to > >>>>>>>> an address other than > >>>>>>> 0. > >>>>>>>> Ugly device, ugly driver. Sigh. > >>>>>>>> > >>>>>>>> > >>>>>>>> This communication may not represent my employer's views, if > >>>>>>>> any, on the matters discussed. > >>>>>>>> > >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>>>>> Thanks Timothe, > >>>>>>>>> > >>>>>>>>> I am pretty sure I am doing all the things you mention already > >>>>>>>>> (sorry I didn't make that clear), but I will check through > >>>>>>>>> everything you have said, just in case I have missed something. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Rob > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>> bounces at trailing- > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>>>> Sent: 19 May 2013 11:26 > >>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>> > >>>>>>>>>> A couple of other things come to mind (naturally, after > >>>>>>>>>> pushing > >>>>>>> 'send'): > >>>>>>>>>> Initialization will load/verify the microcode. That has to > > work. > >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in > >>>>>>>>>> and control-in command to establish the DUP CSR address, > >>>>>>>>>> buffers, line > >>>>>>>> mode/enable. > >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating an > >>>>>>>>>> A vector interrupt. > >>>>>>>>>> > >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>>>>> (BSIO) and bit > >>>>>>>>> clear > >>>>>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>>>>> > >>>>>>>>>> For better directed hints, I'd need more detail on what is and > >>>>>>>>>> isn't > >>>>>>>>> happening. > >>>>>>>>>> This communication may not represent my employer's views, if > >>>>>>>>>> any, on the matters discussed. > >>>>>>>>>> > >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>> bounces at trailing- > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > Code? > >>>>>>>>>>>> > >>>>>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point me > at > >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > KMC11? > >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to do > >>>>>>>>>>>>> something and read back some values, but I don't know > what > >>>>>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>>>>> Hi, Rob, > >>>>>>>>>>>> > >>>>>>>>>>>> http://pdp-10.trailing- > >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>>>>> l > >>>>>>>>>>>> > >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Rich > >>> _______________________________________________ > >>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>>> I am making some progress with getting the KMC/DUP > >> emulation > >>>>>>>> working > >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one thing, > >>>>>>>>>>> which is the interrupts to tell the OS that the KMC has > >>>>>>>>>>> processed a > >>>>>> buffer. > >>>>>>>>>>> The OS sets the interrupt enable bit and when I have > >>>>>>>>>>> something to report to the OS I set the relevant interrupt > >>>>>>>>>>> bit. However, nothing happens when I do that. I am > wondering > >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > > (decimal). > >>>>>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>>>>> > >>>>>>>>>>> Can anyone help? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> > >>>>>>>>>>> Rob > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Simh mailing list > >>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>> _______________________________________________ > >>>>>>> Simh mailing list > >>>>>>> Simh at trailing-edge.com > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > From robert.jarratt at ntlworld.com Sun May 26 04:09:01 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Sun, 26 May 2013 09:09:01 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> Message-ID: <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> Tim, I have been looking very closely at how I am writing to the memory and I cannot see anything obviously wrong. Let me run you through one receive buffer transfer with some extracts from the log, see if you can spot any flaws: On startup I get two receive buffers as follows: DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) DBG(285632654)> KMC CMD: Descriptor for rx buffer: DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor address=0x93C8(111710 octal) DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 sel6=020000 DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) DBG(285632752)> KMC CMD: Descriptor for rx buffer: DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor address=0x9558(112530 octal) A little while later I receive the 6 bytes of data from the peer: DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). Descriptor is: DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to address=0x93D8(111730 octal), bytes=6 dma ub write 0x000093d8=003005(oct) dma ub write 0x000093da=000300(oct) dma ub write 0x000093dc=000400(oct) dma ub write 0x000093cc=101400(oct) So the memory appears to get written correctly to the correct location. I then transfer the buffer out to the OS using an output command (no detailed trace for that), this is immediately followed by me receiving a new receive buffer (the very one I just sent, so I think the output transfer must have worked) and the error from the OS: DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) DBG(582051478)> KMC CMD: Descriptor for rx buffer: DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor address=0x93C8(111710 octal) ******************** *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 *BAD DDCMP HEADER *ADDITIONAL DATA: 746314746314, 746314777777 ******************** My suspicion fell on the code to write the data to the memory, this is the unibus_write code: extern t_stat unibus_write(int32 data, int32 addr) { uint16 d; d = data & 0xFFFF; return Map_WriteW (addr, 2, &d); } Which looks OK to me. Regards Rob > -----Original Message----- > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > edge.com] On Behalf Of Robert Jarratt > Sent: 19 May 2013 22:47 > To: 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Thanks, that sounds likely, I will check how I am writing to memory. > > Regards > > Rob > > > -----Original Message----- > > From: Timothe Litt [mailto:litt at ieee.org] > > Sent: 19 May 2013 21:41 > > To: Robert Jarratt > > Cc: simh at trailing-edge.com > > Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > This is progress. Looks to me like the data isn't being stored properly. > > > > The ADDITIONAL DATA is the first 8 bytes of the data buffer. The > > SKIPL says the sign bit is set (which it is in 7463...). > > That's not possible. > > > > So I suspect you're not writing the data thru the UBA map correctly. > > > > Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > > words packed into 18-bit 1/2 words. > > This looks like: > > > > /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > > / /-- The ENQ goes here > > / / -- The START goes here > > ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! > > byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > > > > Since 00 is constant, the first digit can't be > 1. 7 mumble is. > > > > Thus for 05 06 (ENQ START), we should see something like 3005,,... in > > the first word. > > (5 + 6 << 8) > > > > Also, you need to map the UBA address to PDP-10 memory (which you > seem > > to be doing for reads). > > > > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 19-May-13 16:06, Robert Jarratt wrote: > > > Oops, meant to say the first byte sent is 0x05. > > > > > >> -----Original Message----- > > >> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > > >> Sent: 19 May 2013 21:01 > > >> To: 'Timothe Litt'; 'simh at trailing-edge.com' > > >> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >> > > >> Thanks! There was a bug in my interrupt acknowledge routine. With > > >> that fixed the interrupts now seem to be working OK. I have made > > >> progress, > > with > > >> the two clones talking to each other I get this now: > > >> > > >> > > >> ******************** > > >> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > > >> *BAD DDCMP HEADER > > >> *ADDITIONAL DATA: 746314746314, 746314777777 > > >> ******************** > > >> > > >> I am going to have to re-learn MACRO to work out why it is failing. > > >> The > > > code I > > >> see has two jumps to BUMHDR, I can't work out what the first one > > >> means, the second seems to be checking the first byte, which being > > >> 0x06 should > > be > > >> OK, so it is probably the first condition that is failing. > > >> > > >> Regards > > >> > > >> Rob > > >> > > >> > > >>> -----Original Message----- > > >>> From: simh-bounces at trailing-edge.com > > >>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > > >>> Sent: 19 May 2013 18:01 > > >>> To: simh at trailing-edge.com > > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>> > > >>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT > > >>> "KMCIII". > > >>> > > >>> You need to tell simh what vector to use when you tell it about > > >>> the pending interrupt. Most devices have only one vector. The KMC > (and > > >>> DMC/DMR) have 2. A is the (numerically) first; B is the second. So > in > > >>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber > > >>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being > > granted. > > >>> (Or whatever symbol you used.) A should be generated by RDI; B by > > RDO. > > >>> > > >>> That will tell simh how to find the right service routine. > > >>> > > >>> IIRC, if both happen to be pending at the same time, A takes > > precedence. > > >>> > > >>> Without seeing the code, I can't be more explicit... > > >>> > > >>> Oh, be careful when you talk about bit numbers. The unibus is > > >>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > > >>> > > >>> This communication may not represent my employer's views, if any, > > >>> on the matters discussed. > > >>> > > >>> On 19-May-13 12:36, Robert Jarratt wrote: > > >>>> Hmmm.... I do have RDYO set, but it is supposed to be a B > > >>>> interrupt, not an A, so that would make sense. I have A vectored > > >>>> at bit 8, and B at bit > > >>> 9. > > >>>> Are you referring to this code: > > >>>> > > >>>> ;HERE FOR INPUT INTERRUPTS > > >>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > > >>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > > >>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > > >>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > > >>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > > >>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > > >>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > > >>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? > > >>>> TRNN T2,KMCRDI ;AND IS IT READY ? > > >>>> BUG (KMCIII,<,>) << A interrupt with nothing in the > > >>> driver queue, or RDI not set > > >>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? > > >>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE > > >>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > > >>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > > >>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT > > >>> FLAG << CSR BIT requesting an A interrupt > > >>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > > >>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears request > > >>> when driver queue empty > > >>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > > >>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY > > >>>> << the command is then removed from the driver queue and written > > to > > >>>> the KMC. The KMC > > >>> << must clear RDI until it is ready to take the next command. > > >>> (Note that otherwise if the queue depth >1, the << A interrupt > > >>> will happen immediately. > > >>>> If so, then despite the fact that I am setting bit 9 in the > > >>>> interrupt request, it seems to be going to the A interrupt handler. > > >>>> > > >>>> Regards > > >>>> > > >>>> Rob > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > bounces at trailing- > > >>>>> edge.com] On Behalf Of Timothe Litt > > >>>>> Sent: 19 May 2013 17:01 > > >>>>> Cc: simh at trailing-edge.com > > >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>> > > >>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an > > >>>>> A > > >>>> interrupt. > > >>>>> (KMCRDI is 20; RDO is 200) > > >>>>> > > >>>>> RDYO should always go to IVB; RDYI to IVA. > > >>>>> > > >>>>> Since we took an IVA interrupt, the driver thinks its trying to > > >>>>> give the > > >>>> KMC a > > >>>>> command, but the interrupt is going to the wrong vector since > > >>>>> RDYI is not > > >>>> set. > > >>>>> So either you're generating an IVA but setting the wrong status > > >>>>> bit, or generating an Ivb event but not to the right vector. Or > > >>>>> perhaps you have > > >>>> an > > >>>>> overrun - the interrupt has to be cleared when the drive clears > > >>>>> the RDx > > >>>> bit. > > >>>>> The data looks like a DDCMP start, less the CRCs. That > > >>>>> indicates that a > > >>>> fair bit > > >>>>> of stuff is working; this is the data that the -10 provides to > > >>>>> the > > > KMC. > > >>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header > > >>>>> and > > >>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > > >>>>> CRC errors are reported by control out bits. Since the KMC both > > >>>>> adds on transmit and removes/checks on receive, and you are > > running > > >>>>> over an error- checked transport, you can get away with not > > >>>>> simulating this - unless you want to interoperate with an > > >>>>> interface that does add the > > >>> CRCs. > > >>>>> Even if the systems are cloned, the DDCMP layer should come up; > > >>>>> you'll die later when transport detects a duplicate DECnet node > > > number. > > >>>>> > > >>>>> This communication may not represent my employer's views, if > > >>>>> any, on the matters discussed. > > >>>>> > > >>>>> On 19-May-13 11:01, Robert Jarratt wrote: > > >>>>>> What is curious now is that I have two instances (identical > > >>>>>> clones) > > >>>> running > > >>>>>> attempting to talk to each other. The first message one sends > > >>>>>> to the > > >>>> other > > >>>>>> crashes the OS: > > >>>>>> > > >>>>>> ********** > > >>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > > >>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > > >>>>>> ********** > > >>>>>> > > >>>>>> The odd thing is that I have delivered the same data that was > > >>>>>> sent from > > >>>> the > > >>>>>> other end, so it should be valid data. > > >>>>>> > > >>>>>> The data is: 05 06 C0 00 00 01 > > >>>>>> > > >>>>>> That data does not seem to completely match the DDCMP spec I > > have, > > >>>>>> I > > >>>>> think > > >>>>>> some checksum is supposed to follow. Is that supposed to be > > >>>>>> added by the > > >>>>> KMC > > >>>>>> perhaps? > > >>>>>> > > >>>>>> I don't fully expect it to work because they are clones so > > >>>>>> would expect > > >>>>> some > > >>>>>> kind of error, but would not expect a crash, or am I wrong? > > >>>>>> > > >>>>>> Regards > > >>>>>> > > >>>>>> Rob > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>> bounces at trailing- > > >>>>>>> edge.com] On Behalf Of Robert Jarratt > > >>>>>>> Sent: 19 May 2013 15:21 > > >>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > > >>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>> > > >>>>>>> I have made some progress. I realised that I did not have the > > >>>>>>> interrupt acknowledgement routines set up in the DIB. It is > > >>>>>>> working a bit better > > >>>>>> now. > > >>>>>>> I have indeed seen some commands to read the ram and verify > > >>>>>>> the microcode, it does all this to check the KMC is working > > >>>>>>> before enabling > > >>>>>> it. > > >>>>>>> This particular code has never (as far as I know) worked for > > >>>>>>> the > > >>>>>>> 11 or > > >>>> the > > >>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > > >>>>>>> with now came from someone else and was written for the > PDP1) > > for > > >>>>>>> a > > >>> much > > >>>>>>> older version of SIMH. > > >>>>>>> > > >>>>>>> Regards > > >>>>>>> > > >>>>>>> Rob > > >>>>>>> > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: simh-bounces at trailing-edge.com > > >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of > Timothe > > >>>>>>>> Litt > > >>>>>>>> Sent: 19 May 2013 14:54 > > >>>>>>>> To: simh at trailing-edge.com > > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>> > > >>>>>>>>> I am pretty sure I am doing all the things you mention > > >>>>>>>>> already > > >>>>>>>> Then I need a trace of what's happening to the registers, and > > >>>>>>>> what > > >>>> simh > > >>>>>>>> thinks it's doing with the interrupts. (It would be easiest to > > >>>> follow > > >>>>>>>> if you output both octal and decode the register > > >>>>>>>> names/fields, though I > > >>>>>>> can > > >>>>>>>> still think - slowly- in octal.) > > >>>>>>>> > > >>>>>>>> Also, I thought this code was working for the -11/VAX. If > > >>>>>>>> so, the basics > > >>>>>>> must > > >>>>>>>> be OK, though the drivers may well take a different approach > > >>>>>>>> to the > > >>>>>>> device. > > >>>>>>>> Received data should produce either a control-out (error, e.g. > > >>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out > > >>>>>>>> B > > >> interrupt. > > >>>>>>>> The > > >>>>>>> message > > >>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > > >>>>>>>> > > >>>>>>>> Transmit done - also note that we ignore interrupts unless > > >>>>>>>> the 'last > > >>>>>>> buffer' bit > > >>>>>>>> is set. (The DDCMP header and data are in two BDL segments, > > >>>>>>>> and require two interrupts.) > > >>>>>>>> > > >>>>>>>> Finally, I'm not sure if you'll see it used, but there is > > >>>>>>>> code in the > > >>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > > (KMCSUP > > >>>>>>>> 400) > > >>>>> to > > >>>>>>>> force the microcontroller to execute several known > > >>>>>>>> instructions > > >>>>>>>> - to > > >>>>>>> access its > > >>>>>>>> data ram, registers & PC. This is primarily used to dump a > > >>>>>>>> KMC that halts > > >>>>>>> - it > > >>>>>>>> doesn't seem to be used when the built-in ucode is loaded. > > >>>>>>>> But some of these are also used to verify data ram at > initialization. > > >>>>>>>> Failure to > > >>>>>>> verify will > > >>>>>>>> cause the device to be disabled. We can go down that path if > > >>>>>>>> you see > > >>>>>>> those > > >>>>>>>> bits being set in a trace. > > >>>>>>>> > > >>>>>>>> Look for KMCXCT calls in > > >>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > > >>>>>>>> sources/kdpsrv.mac.html > > >>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined > > >>>>>>>> in > > >>>>>>>> http://bitsavers.trailing- > > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > > OP- > > >>>>>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > > >>>>>>>> nual.pdf > > >>>>>>>> > >>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- > > OP- > > >>>>>>>> > > >> > > > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > > >>>>>>>> 0Manual.pdf> > > >>>>>>>> The subset is pretty small - load address register, > > >>>>>>>> load/store indirect > > >>>>>>> (with > > >>>>>>>> increment), & branch. I think you ought to be able to crash > > >>>>>>>> simh if an unknown instruction is forced, including a branch > > >>>>>>>> to an address other than > > >>>>>>> 0. > > >>>>>>>> Ugly device, ugly driver. Sigh. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This communication may not represent my employer's views, if > > >>>>>>>> any, on the matters discussed. > > >>>>>>>> > > >>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > > >>>>>>>>> Thanks Timothe, > > >>>>>>>>> > > >>>>>>>>> I am pretty sure I am doing all the things you mention > > >>>>>>>>> already (sorry I didn't make that clear), but I will check > > >>>>>>>>> through everything you have said, just in case I have missed > something. > > >>>>>>>>> > > >>>>>>>>> Regards > > >>>>>>>>> > > >>>>>>>>> Rob > > >>>>>>>>> > > >>>>>>>>>> -----Original Message----- > > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>> bounces at trailing- > > >>>>>>>>>> edge.com] On Behalf Of Timothe Litt > > >>>>>>>>>> Sent: 19 May 2013 11:26 > > >>>>>>>>>> To: simh at trailing-edge.com > > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > > >>>>>>>>>> > > >>>>>>>>>> A couple of other things come to mind (naturally, after > > >>>>>>>>>> pushing > > >>>>>>> 'send'): > > >>>>>>>>>> Initialization will load/verify the microcode. That has to > > > work. > > >>>>>>>>>> After setting RUN and the interrupt enables, expect base-in > > >>>>>>>>>> and control-in command to establish the DUP CSR address, > > >>>>>>>>>> buffers, line > > >>>>>>>> mode/enable. > > >>>>>>>>>> These require that the KMC respond to KMCRQI by initiating > > >>>>>>>>>> an A vector interrupt. > > >>>>>>>>>> > > >>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > > >>>>>>>>>> (BSIO) and bit > > >>>>>>>>> clear > > >>>>>>>>>> (BCIO) instructions that also touch the KMC. > > >>>>>>>>>> > > >>>>>>>>>> For better directed hints, I'd need more detail on what is > > >>>>>>>>>> and isn't > > >>>>>>>>> happening. > > >>>>>>>>>> This communication may not represent my employer's views, > > >>>>>>>>>> if any, on the matters discussed. > > >>>>>>>>>> > > >>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > > >>>>>>>>>>>> -----Original Message----- > > >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > > >>>>>>>> bounces at trailing- > > >>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > > >>>>>>>>>>>> Sent: 08 May 2013 01:02 > > >>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > > >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > > Code? > > >>>>>>>>>>>> > > >>>>>>>>>>>>> From: "Robert Jarratt" > > >>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point > me > > at > > >>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > > KMC11? > > >>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to > > >>>>>>>>>>>>> do something and read back some values, but I don't > know > > what > > >>>>>>>>>>>>> values it wants to get and so it reports: > > >>>>>>>>>>>> Hi, Rob, > > >>>>>>>>>>>> > > >>>>>>>>>>>> http://pdp-10.trailing- > > >>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > > >>>>>>>>>>>> l > > >>>>>>>>>>>> > > >>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> Rich > > >>> _______________________________________________ > > >>>>>>>>>>>> Simh mailing list > > >>>>>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>>>>>> I am making some progress with getting the KMC/DUP > > >> emulation > > >>>>>>>> working > > >>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one > > >>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC > > >>>>>>>>>>> has processed a > > >>>>>> buffer. > > >>>>>>>>>>> The OS sets the interrupt enable bit and when I have > > >>>>>>>>>>> something to report to the OS I set the relevant interrupt > > >>>>>>>>>>> bit. However, nothing happens when I do that. I am > > wondering > > >>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > > > (decimal). > > >>>>>>>>>>> I am not sure how to find out which bit I should be setting. > > >>>>>>>>>>> > > >>>>>>>>>>> Can anyone help? > > >>>>>>>>>>> > > >>>>>>>>>>> Regards > > >>>>>>>>>>> > > >>>>>>>>>>> Rob > > >>>>>>>>>>> > > >>>>>>>>>>> > _______________________________________________ > > >>>>>>>>>>> Simh mailing list > > >>>>>>>>>>> Simh at trailing-edge.com > > >>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > >>>>>>> _______________________________________________ > > >>>>>>> Simh mailing list > > >>>>>>> Simh at trailing-edge.com > > >>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From litt at ieee.org Sun May 26 06:25:21 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 26 May 2013 06:25:21 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> Message-ID: <51A1E311.4040109@ieee.org> 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...) 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. TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when the buffer is received. This is a paranoia check to see if the KMC is returning a buffer that it didn't write to. Also, the real UBA wouldn't do a read-modify-write on the first 16-bit write (unless read-reverse was set in the UBA map entry). It would simply write the first word. The odd word is also done as a simple write because the UBA saves the even word's data - that's roughly equivalent to RMW. (See http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM-002_tech_Sep79.pdf around page 5-119 for the gory details, including other transfer modes.) Third: The additional data in the bugchk is the 10-side view of the buffer's first two 36-bit words. This is not the correct data. Note that 3 16-bit words are written, which corresponds to your 6 bytes. But the data is the same (0746314) in each word. The unwritten word is 0777777, which is a good sign that the mapping is correct (though not what a real UBA would do). If we clear the two high bits of the data, we get 0146314, which is 0xCCcc. 0xcc happens to be the low byte of the last DMA UB WRITE's address. Perhaps the address and data arguments to your unibus_write routine are swapped? You might want to look at pdp10_tu.c for a more efficient way of doing large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive unibus mapping only once per page, and writes directly to -10 memory - bypassing the bug in Map_WriteW. It also handles NXM reporting, which hopefully the caller to your interface code is doing... Note, though, that the tu works thru a RH11, which is an 18-bit device and the tape is packing bytes into 36-bit words in odd ways. Don't let that confuse you. Yes, KDPSRV will always return the same buffers; that's expected. It has statically allocated buffers for each line's transmit and receive and copies data in and out. This is partly due to byte re-ordering and partly a matter of simplifying UBA mapping register management. This communication may not represent my employer's views, if any, on the matters discussed. On 26-May-13 04:09, Robert Jarratt wrote: > Tim, > > I have been looking very closely at how I am writing to the memory and I > cannot see anything obviously wrong. Let me run you through one receive > buffer transfer with some extracts from the log, see if you can spot any > flaws: > > On startup I get two receive buffers as follows: > > DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 > DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > DBG(285632654)> KMC CMD: Descriptor for rx buffer: > DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) > DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor > address=0x93C8(111710 octal) > > DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 sel6=020000 > DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) > DBG(285632752)> KMC CMD: Descriptor for rx buffer: > DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) > DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor > address=0x9558(112530 octal) > > A little while later I receive the 6 bytes of data from the peer: > > DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 > DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). Descriptor > is: > DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) > DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) > DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) > DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to address=0x93D8(111730 > octal), bytes=6 > dma ub write 0x000093d8=003005(oct) > dma ub write 0x000093da=000300(oct) > dma ub write 0x000093dc=000400(oct) > dma ub write 0x000093cc=101400(oct) > > So the memory appears to get written correctly to the correct location. I > then transfer the buffer out to the OS using an output command (no detailed > trace for that), this is immediately followed by me receiving a new receive > buffer (the very one I just sent, so I think the output transfer must have > worked) and the error from the OS: > > DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 sel6=020000 > DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > DBG(582051478)> KMC CMD: Descriptor for rx buffer: > DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) > DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) > DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) > DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor > address=0x93C8(111710 octal) > > ******************** > *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 > *BAD DDCMP HEADER > *ADDITIONAL DATA: 746314746314, 746314777777 > ******************** > > My suspicion fell on the code to write the data to the memory, this is the > unibus_write code: > > extern t_stat unibus_write(int32 data, int32 addr) > { > uint16 d; > > d = data & 0xFFFF; > > return Map_WriteW (addr, 2, &d); > } > > Which looks OK to me. > > Regards > > Rob > >> -----Original Message----- >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >> edge.com] On Behalf Of Robert Jarratt >> Sent: 19 May 2013 22:47 >> To: 'Timothe Litt' >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >> >> Thanks, that sounds likely, I will check how I am writing to memory. >> >> Regards >> >> Rob >> >>> -----Original Message----- >>> From: Timothe Litt [mailto:litt at ieee.org] >>> Sent: 19 May 2013 21:41 >>> To: Robert Jarratt >>> Cc: simh at trailing-edge.com >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>> >>> This is progress. Looks to me like the data isn't being stored > properly. >>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The >>> SKIPL says the sign bit is set (which it is in 7463...). >>> That's not possible. >>> >>> So I suspect you're not writing the data thru the UBA map correctly. >>> >>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit >>> words packed into 18-bit 1/2 words. >>> This looks like: >>> >>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE >>> / /-- The ENQ goes here >>> / / -- The START goes here >>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! >>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 >>> >>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. >>> >>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in >>> the first word. >>> (5 + 6 << 8) >>> >>> Also, you need to map the UBA address to PDP-10 memory (which you >> seem >>> to be doing for reads). >>> >>> >>> This communication may not represent my employer's views, if any, on >>> the matters discussed. >>> >>> On 19-May-13 16:06, Robert Jarratt wrote: >>>> Oops, meant to say the first byte sent is 0x05. >>>> >>>>> -----Original Message----- >>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >>>>> Sent: 19 May 2013 21:01 >>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' >>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> Thanks! There was a bug in my interrupt acknowledge routine. With >>>>> that fixed the interrupts now seem to be working OK. I have made >>>>> progress, >>> with >>>>> the two clones talking to each other I get this now: >>>>> >>>>> >>>>> ******************** >>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >>>>> *BAD DDCMP HEADER >>>>> *ADDITIONAL DATA: 746314746314, 746314777777 >>>>> ******************** >>>>> >>>>> I am going to have to re-learn MACRO to work out why it is failing. >>>>> The >>>> code I >>>>> see has two jumps to BUMHDR, I can't work out what the first one >>>>> means, the second seems to be checking the first byte, which being >>>>> 0x06 should >>> be >>>>> OK, so it is probably the first condition that is failing. >>>>> >>>>> Regards >>>>> >>>>> Rob >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: simh-bounces at trailing-edge.com >>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt >>>>>> Sent: 19 May 2013 18:01 >>>>>> To: simh at trailing-edge.com >>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>> >>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => BUGHLT >>>>>> "KMCIII". >>>>>> >>>>>> You need to tell simh what vector to use when you tell it about >>>>>> the pending interrupt. Most devices have only one vector. The KMC >> (and >>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. > So >> in >>>>>> the interrupt ack routine, you need to return VEC_KDP * kmcnumber >>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being >>> granted. >>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by >>> RDO. >>>>>> That will tell simh how to find the right service routine. >>>>>> >>>>>> IIRC, if both happen to be pending at the same time, A takes >>> precedence. >>>>>> Without seeing the code, I can't be more explicit... >>>>>> >>>>>> Oh, be careful when you talk about bit numbers. The unibus is >>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>>>>> >>>>>> This communication may not represent my employer's views, if any, >>>>>> on the matters discussed. >>>>>> >>>>>> On 19-May-13 12:36, Robert Jarratt wrote: >>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B >>>>>>> interrupt, not an A, so that would make sense. I have A vectored >>>>>>> at bit 8, and B at bit >>>>>> 9. >>>>>>> Are you referring to this code: >>>>>>> >>>>>>> ;HERE FOR INPUT INTERRUPTS >>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE DIFFERENT ? >>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing in > the >>>>>> driver queue, or RDI not set >>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND AGAIN ? >>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF QUEUE >>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST INPUT >>>>>> FLAG << CSR BIT requesting an A interrupt >>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears > request >>>>>> when driver queue empty >>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE ENTRY >>>>>>> << the command is then removed from the driver queue and written >>> to >>>>>>> the KMC. The KMC >>>>>> << must clear RDI until it is ready to take the next command. >>>>>> (Note that otherwise if the queue depth >1, the << A interrupt >>>>>> will happen immediately. >>>>>>> If so, then despite the fact that I am setting bit 9 in the >>>>>>> interrupt request, it seems to be going to the A interrupt handler. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>> bounces at trailing- >>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>> Sent: 19 May 2013 17:01 >>>>>>>> Cc: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an >>>>>>>> A >>>>>>> interrupt. >>>>>>>> (KMCRDI is 20; RDO is 200) >>>>>>>> >>>>>>>> RDYO should always go to IVB; RDYI to IVA. >>>>>>>> >>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>>>>> give the >>>>>>> KMC a >>>>>>>> command, but the interrupt is going to the wrong vector since >>>>>>>> RDYI is not >>>>>>> set. >>>>>>>> So either you're generating an IVA but setting the wrong status >>>>>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>>>>> perhaps you have >>>>>>> an >>>>>>>> overrun - the interrupt has to be cleared when the drive clears >>>>>>>> the RDx >>>>>>> bit. >>>>>>>> The data looks like a DDCMP start, less the CRCs. That >>>>>>>> indicates that a >>>>>>> fair bit >>>>>>>> of stuff is working; this is the data that the -10 provides to >>>>>>>> the >>>> KMC. >>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. (Header >>>>>>>> and >>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. >>>>>>>> CRC errors are reported by control out bits. Since the KMC both >>>>>>>> adds on transmit and removes/checks on receive, and you are >>> running >>>>>>>> over an error- checked transport, you can get away with not >>>>>>>> simulating this - unless you want to interoperate with an >>>>>>>> interface that does add the >>>>>> CRCs. >>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>>>>> you'll die later when transport detects a duplicate DECnet node >>>> number. >>>>>>>> This communication may not represent my employer's views, if >>>>>>>> any, on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>>>>> What is curious now is that I have two instances (identical >>>>>>>>> clones) >>>>>>> running >>>>>>>>> attempting to talk to each other. The first message one sends >>>>>>>>> to the >>>>>>> other >>>>>>>>> crashes the OS: >>>>>>>>> >>>>>>>>> ********** >>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>>>>> ********** >>>>>>>>> >>>>>>>>> The odd thing is that I have delivered the same data that was >>>>>>>>> sent from >>>>>>> the >>>>>>>>> other end, so it should be valid data. >>>>>>>>> >>>>>>>>> The data is: 05 06 C0 00 00 01 >>>>>>>>> >>>>>>>>> That data does not seem to completely match the DDCMP spec I >>> have, >>>>>>>>> I >>>>>>>> think >>>>>>>>> some checksum is supposed to follow. Is that supposed to be >>>>>>>>> added by the >>>>>>>> KMC >>>>>>>>> perhaps? >>>>>>>>> >>>>>>>>> I don't fully expect it to work because they are clones so >>>>>>>>> would expect >>>>>>>> some >>>>>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>>>>> Sent: 19 May 2013 15:21 >>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> I have made some progress. I realised that I did not have the >>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>>>>> working a bit better >>>>>>>>> now. >>>>>>>>>> I have indeed seen some commands to read the ram and verify >>>>>>>>>> the microcode, it does all this to check the KMC is working >>>>>>>>>> before enabling >>>>>>>>> it. >>>>>>>>>> This particular code has never (as far as I know) worked for >>>>>>>>>> the >>>>>>>>>> 11 or >>>>>>> the >>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>>>>> with now came from someone else and was written for the >> PDP1) >>> for >>>>>>>>>> a >>>>>> much >>>>>>>>>> older version of SIMH. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Rob >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of >> Timothe >>>>>>>>>>> Litt >>>>>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>> >>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>> already >>>>>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>>>>> what >>>>>>> simh >>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest > to >>>>>>> follow >>>>>>>>>>> if you output both octal and decode the register >>>>>>>>>>> names/fields, though I >>>>>>>>>> can >>>>>>>>>>> still think - slowly- in octal.) >>>>>>>>>>> >>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If >>>>>>>>>>> so, the basics >>>>>>>>>> must >>>>>>>>>>> be OK, though the drivers may well take a different approach >>>>>>>>>>> to the >>>>>>>>>> device. >>>>>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out >>>>>>>>>>> B >>>>> interrupt. >>>>>>>>>>> The >>>>>>>>>> message >>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>>>>> >>>>>>>>>>> Transmit done - also note that we ignore interrupts unless >>>>>>>>>>> the 'last >>>>>>>>>> buffer' bit >>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, >>>>>>>>>>> and require two interrupts.) >>>>>>>>>>> >>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is >>>>>>>>>>> code in the >>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step >>> (KMCSUP >>>>>>>>>>> 400) >>>>>>>> to >>>>>>>>>>> force the microcontroller to execute several known >>>>>>>>>>> instructions >>>>>>>>>>> - to >>>>>>>>>> access its >>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a >>>>>>>>>>> KMC that halts >>>>>>>>>> - it >>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. >>>>>>>>>>> But some of these are also used to verify data ram at >> initialization. >>>>>>>>>>> Failure to >>>>>>>>>> verify will >>>>>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>>>>> you see >>>>>>>>>> those >>>>>>>>>>> bits being set in a trace. >>>>>>>>>>> >>>>>>>>>>> Look for KMCXCT calls in >>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>>>>> sources/kdpsrv.mac.html >>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined >>>>>>>>>>> in >>>>>>>>>>> http://bitsavers.trailing- >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- >>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>>>>> nual.pdf >>>>>>>>>>> >>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK-KMC11- >>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>>>>> 0Manual.pdf> >>>>>>>>>>> The subset is pretty small - load address register, >>>>>>>>>>> load/store indirect >>>>>>>>>> (with >>>>>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>>>>> simh if an unknown instruction is forced, including a branch >>>>>>>>>>> to an address other than >>>>>>>>>> 0. >>>>>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>>> any, on the matters discussed. >>>>>>>>>>> >>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>>>>> Thanks Timothe, >>>>>>>>>>>> >>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>> already (sorry I didn't make that clear), but I will check >>>>>>>>>>>> through everything you have said, just in case I have missed >> something. >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>>> >>>>>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>>>>> pushing >>>>>>>>>> 'send'): >>>>>>>>>>>>> Initialization will load/verify the microcode. That has to >>>> work. >>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base-in >>>>>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>>>>> buffers, line >>>>>>>>>>> mode/enable. >>>>>>>>>>>>> These require that the KMC respond to KMCRQI by initiating >>>>>>>>>>>>> an A vector interrupt. >>>>>>>>>>>>> >>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>>>>> (BSIO) and bit >>>>>>>>>>>> clear >>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>>>>> >>>>>>>>>>>>> For better directed hints, I'd need more detail on what is >>>>>>>>>>>>> and isn't >>>>>>>>>>>> happening. >>>>>>>>>>>>> This communication may not represent my employer's views, >>>>>>>>>>>>> if any, on the matters discussed. >>>>>>>>>>>>> >>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >>> Code? >>>>>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point >> me >>> at >>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the >>> KMC11? >>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to >>>>>>>>>>>>>>>> do something and read back some values, but I don't >> know >>> what >>>>>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rich >>>>>> _______________________________________________ >>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP >>>>> emulation >>>>>>>>>>> working >>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one >>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC >>>>>>>>>>>>>> has processed a >>>>>>>>> buffer. >>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am >>> wondering >>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 >>>> (decimal). >>>>>>>>>>>>>> I am not sure how to find out which bit I should be setting. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can anyone help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>> _______________________________________________ >>>>>>>>>> Simh mailing list >>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >> >> _______________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From radioengr at gmail.com Sun May 26 12:01:32 2013 From: radioengr at gmail.com (Rob Doyle) Date: Sun, 26 May 2013 09:01:32 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A1E311.4040109@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> Message-ID: <51A231DC.60708@gmail.com> On 5/26/2013 3:25 AM, Timothe Litt wrote: > 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. ...but not unconditionally, right? The KS10 needs to do 18-bit IO for the disk interfaces. The UBA bridge can be configured to do 18-bit IO or 16-bit IO. See DISABLE bit in the UBA paging RAM in the technical spec that you referenced on page 5-105. (I didn't look to see if that was implemented correctly in SIMH) Rob Doyle From litt at ieee.org Sun May 26 12:50:55 2013 From: litt at ieee.org (Timothe Litt) Date: Sun, 26 May 2013 12:50:55 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A231DC.60708@gmail.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <51A231DC.60708@gmail.com> Message-ID: <51A23D6F.7020203@ieee.org> > ...but not unconditionally, right? Valid concern, but the devil is in the details. My note was carefully phrased. The disable bit only effects NPR reads; it replaces the two high bits as they are transferred to the Unibus. This is because on a normal (16-bit) unibus, these are PA and PB (byte parity). If they were were transfered, they could cause Unibus parity errors in some 16-bit devices. This is mostly ignored in simh. The tape errors if DISABLE is set, as it knows it's an 18-bit device. (pdp10_ty.c:282) This isn't faithful to the hardware. (The RH has no visibility to the UBA paging RAM, so it would just write zeros to where those bits get swizzled on the tape.) But it would catch an OS programming error. The disable bit can be ignored by 16-bit device emulations since they don't get or check unibus parity. (And if you're tempted to implement some error, note that TOPS-20 doesn't set it for the KDP even though it should.) NPR writes are rather more involved per the spec I cited. Basically, the UBA tries to minimize KS bus transactions by avoiding RPW when possible. It takes advantage of the fact that NPR transfers are to increasing (or with read reverse, decreasing) addresses & caches half words. So writing word 0 (high 1/2 word) will save the data, allowing the next NPR write to merge with the saved data, allowing a KS write cycle (rather than RPW). For read reverse, same idea but backwards. The data comes from the Unibus; 16-bt devices drive or default PA & PB as zero unless they implement parity. Aside from memory, very few do. 18-bit devices are unique to the KS10; IIRC, only the RH11-C uses PA & PB for data. (At one point I considered creating an 18-bit UDA50 variant, but never did.) The disk and tape versions differ slightly in that the disk controller uses bus hog mode. See P 5-94 - 5-100. Note that in figure 5-47, NPR byte writes (which the KMC does) write 0s in the high bits. This is what's not being emulated. NPR word writes could be 16 or 18 bits; the high 2 bits come from the Unibus, but as 16-bit IO devices don't drive them, they default to zero. Simh devices need to treat the high bits as the real devices would. The Map_WriteW routine probably should be taking 18 bit data, with the caller deciding what to put in the high two bits. But that's inconvenient, because C has a 16-bit datatype. So it could use a void * with a mode flag, or have two routines, or... But since the only known 18-bit devices are the RH11s and they don't use this routine, simh could get by with simply clearing the bits. Or as I suggested, the KMC would be better served doing what the RH emulators do & writing memory directly. This would save many redundant UBA page translations when long messages are transferred, as well as avoid this bug. As I pointed out, pdp10_tu.c (and pdp10_rp.c) don't use the routine in question; they directly map unibus addresses to/from PDP-10 memory & write the full 360bt word. (e.g pdp10_tu.c:906 in the loop starting at :896). I was the last maintainer of the DECSYSTEM-2020, and haven't forgotten everything...yet :-) This communication may not represent my employer's views, if any, on the matters discussed. On 26-May-13 12:01, Rob Doyle wrote: > On 5/26/2013 3:25 AM, Timothe Litt wrote: > >> 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. > > ...but not unconditionally, right? > > The KS10 needs to do 18-bit IO for the disk interfaces. The UBA > bridge can be configured to do 18-bit IO or 16-bit IO. > > See DISABLE bit in the UBA paging RAM in the technical spec that you > referenced on page 5-105. > > (I didn't look to see if that was implemented correctly in SIMH) > > Rob Doyle -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Mon May 27 05:48:19 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 10:48:19 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A1E311.4040109@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> Message-ID: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> > -----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 > > TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing > the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when > the buffer is received. This is a paranoia check to see if the KMC is > returning a buffer that it didn't write to. > > Also, the real UBA wouldn't do a read-modify-write on the first 16-bit > write (unless read-reverse was set in the UBA map entry). It would > simply write the first word. The odd word is also done as a simple > write because the UBA saves the even word's data - that's roughly > equivalent to RMW. (See > http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM- > 002_tech_Sep79.pdf > around page 5-119 for the gory details, including other transfer modes.) > > Third: The additional data in the bugchk is the 10-side view of the > buffer's first two 36-bit words. This is not the correct data. Note > that 3 16-bit words are written, which corresponds to your 6 bytes. But > the data is the same (0746314) in each word. The unwritten word is > 0777777, which is a good sign that the mapping is correct (though not > what a real UBA would do). If we clear the two high bits of the data, > we get 0146314, which is 0xCCcc. > > 0xcc happens to be the low byte of the last DMA UB WRITE's address. > Perhaps the address and data arguments to your unibus_write routine are > swapped? This bit had me stumped until I really checked what was going on in Map_WriteW. I think there is a bug in it on this line: for ( ; ba < lim; ba++) { /* by bytes */ It should be for ( ; ba < lim; ba += 2) { /* by bytes */ That is why 0xCCCC was getting written to the memory. Now I can see that the right data gets into the OS because I temporarily provoked the bugchk again by not clearing the bits, the additional data looked correct this time. However, I still see one end repeatedly sending the first DDCMP message (05 06 C0 00 00 01), but nothing else happens, no response going the other way, no messages on the console etc. I notice that I do get this message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still don't have the right version of DECnet on this virtual machine? Thanks! Rob > > You might want to look at pdp10_tu.c for a more efficient way of doing > large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive > unibus mapping only once per page, and writes directly to -10 memory - > bypassing the bug in Map_WriteW. It also handles NXM reporting, which > hopefully the caller to your interface code is doing... It looks like rather than patch Map_WriteW above it would be better to write a couple of general DMA routines for transferring large buffers. I will try to do that, let's see if I understand everything you and Rob Doyle have said.... > > Note, though, that the tu works thru a RH11, which is an 18-bit device > and the tape is packing bytes into 36-bit words in odd ways. Don't let > that confuse you. > > Yes, KDPSRV will always return the same buffers; that's expected. It has > statically allocated buffers for each line's transmit and receive and > copies data in and out. This is partly due to byte re-ordering and > partly a matter of simplifying UBA mapping register management. > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 26-May-13 04:09, Robert Jarratt wrote: > > Tim, > > > > I have been looking very closely at how I am writing to the memory and I > > cannot see anything obviously wrong. Let me run you through one receive > > buffer transfer with some extracts from the log, see if you can spot any > > flaws: > > > > On startup I get two receive buffers as follows: > > > > DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 > sel6=020000 > > DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > > DBG(285632654)> KMC CMD: Descriptor for rx buffer: > > DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) > > DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor > > address=0x93C8(111710 octal) > > > > DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 > sel6=020000 > > DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) > > DBG(285632752)> KMC CMD: Descriptor for rx buffer: > > DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) > > DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor > > address=0x9558(112530 octal) > > > > A little while later I receive the 6 bytes of data from the peer: > > > > DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 > > DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). > Descriptor > > is: > > DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) > > DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) > > DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) > > DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to > address=0x93D8(111730 > > octal), bytes=6 > > dma ub write 0x000093d8=003005(oct) > > dma ub write 0x000093da=000300(oct) > > dma ub write 0x000093dc=000400(oct) > > dma ub write 0x000093cc=101400(oct) > > > > So the memory appears to get written correctly to the correct location. I > > then transfer the buffer out to the OS using an output command (no > detailed > > trace for that), this is immediately followed by me receiving a new receive > > buffer (the very one I just sent, so I think the output transfer must have > > worked) and the error from the OS: > > > > DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 > sel6=020000 > > DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) > > DBG(582051478)> KMC CMD: Descriptor for rx buffer: > > DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) > > DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) > > DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) > > DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor > > address=0x93C8(111710 octal) > > > > ******************** > > *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 > > *BAD DDCMP HEADER > > *ADDITIONAL DATA: 746314746314, 746314777777 > > ******************** > > > > My suspicion fell on the code to write the data to the memory, this is the > > unibus_write code: > > > > extern t_stat unibus_write(int32 data, int32 addr) > > { > > uint16 d; > > > > d = data & 0xFFFF; > > > > return Map_WriteW (addr, 2, &d); > > } > > > > Which looks OK to me. > > > > Regards > > > > Rob > > > >> -----Original Message----- > >> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- > >> edge.com] On Behalf Of Robert Jarratt > >> Sent: 19 May 2013 22:47 > >> To: 'Timothe Litt' > >> Cc: simh at trailing-edge.com > >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >> > >> Thanks, that sounds likely, I will check how I am writing to memory. > >> > >> Regards > >> > >> Rob > >> > >>> -----Original Message----- > >>> From: Timothe Litt [mailto:litt at ieee.org] > >>> Sent: 19 May 2013 21:41 > >>> To: Robert Jarratt > >>> Cc: simh at trailing-edge.com > >>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>> > >>> This is progress. Looks to me like the data isn't being stored > > properly. > >>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The > >>> SKIPL says the sign bit is set (which it is in 7463...). > >>> That's not possible. > >>> > >>> So I suspect you're not writing the data thru the UBA map correctly. > >>> > >>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit > >>> words packed into 18-bit 1/2 words. > >>> This looks like: > >>> > >>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE > >>> / /-- The ENQ goes here > >>> / / -- The START goes here > >>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! > >>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 > >>> > >>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. > >>> > >>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in > >>> the first word. > >>> (5 + 6 << 8) > >>> > >>> Also, you need to map the UBA address to PDP-10 memory (which you > >> seem > >>> to be doing for reads). > >>> > >>> > >>> This communication may not represent my employer's views, if any, on > >>> the matters discussed. > >>> > >>> On 19-May-13 16:06, Robert Jarratt wrote: > >>>> Oops, meant to say the first byte sent is 0x05. > >>>> > >>>>> -----Original Message----- > >>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] > >>>>> Sent: 19 May 2013 21:01 > >>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' > >>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>> > >>>>> Thanks! There was a bug in my interrupt acknowledge routine. With > >>>>> that fixed the interrupts now seem to be working OK. I have made > >>>>> progress, > >>> with > >>>>> the two clones talking to each other I get this now: > >>>>> > >>>>> > >>>>> ******************** > >>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 > >>>>> *BAD DDCMP HEADER > >>>>> *ADDITIONAL DATA: 746314746314, 746314777777 > >>>>> ******************** > >>>>> > >>>>> I am going to have to re-learn MACRO to work out why it is failing. > >>>>> The > >>>> code I > >>>>> see has two jumps to BUMHDR, I can't work out what the first one > >>>>> means, the second seems to be checking the first byte, which being > >>>>> 0x06 should > >>> be > >>>>> OK, so it is probably the first condition that is failing. > >>>>> > >>>>> Regards > >>>>> > >>>>> Rob > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: simh-bounces at trailing-edge.com > >>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt > >>>>>> Sent: 19 May 2013 18:01 > >>>>>> To: simh at trailing-edge.com > >>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>> > >>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => > BUGHLT > >>>>>> "KMCIII". > >>>>>> > >>>>>> You need to tell simh what vector to use when you tell it about > >>>>>> the pending interrupt. Most devices have only one vector. The KMC > >> (and > >>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. > > So > >> in > >>>>>> the interrupt ack routine, you need to return VEC_KDP * > kmcnumber > >>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being > >>> granted. > >>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by > >>> RDO. > >>>>>> That will tell simh how to find the right service routine. > >>>>>> > >>>>>> IIRC, if both happen to be pending at the same time, A takes > >>> precedence. > >>>>>> Without seeing the code, I can't be more explicit... > >>>>>> > >>>>>> Oh, be careful when you talk about bit numbers. The unibus is > >>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). > >>>>>> > >>>>>> This communication may not represent my employer's views, if any, > >>>>>> on the matters discussed. > >>>>>> > >>>>>> On 19-May-13 12:36, Robert Jarratt wrote: > >>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B > >>>>>>> interrupt, not an A, so that would make sense. I have A vectored > >>>>>>> at bit 8, and B at bit > >>>>>> 9. > >>>>>>> Are you referring to this code: > >>>>>>> > >>>>>>> ;HERE FOR INPUT INTERRUPTS > >>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG > >>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER > >>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS > >>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK > >>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW > >>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG > >>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER > >>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE > DIFFERENT ? > >>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? > >>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing > in > > the > >>>>>> driver queue, or RDI not set > >>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND > AGAIN ? > >>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF > QUEUE > >>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY > >>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER > >>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST > INPUT > >>>>>> FLAG << CSR BIT requesting an A interrupt > >>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? > >>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears > > request > >>>>>> when driver queue empty > >>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY > >>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE > ENTRY > >>>>>>> << the command is then removed from the driver queue and > written > >>> to > >>>>>>> the KMC. The KMC > >>>>>> << must clear RDI until it is ready to take the next command. > >>>>>> (Note that otherwise if the queue depth >1, the << A interrupt > >>>>>> will happen immediately. > >>>>>>> If so, then despite the fact that I am setting bit 9 in the > >>>>>>> interrupt request, it seems to be going to the A interrupt handler. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Rob > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>> bounces at trailing- > >>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>> Sent: 19 May 2013 17:01 > >>>>>>>> Cc: simh at trailing-edge.com > >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>> > >>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an > >>>>>>>> A > >>>>>>> interrupt. > >>>>>>>> (KMCRDI is 20; RDO is 200) > >>>>>>>> > >>>>>>>> RDYO should always go to IVB; RDYI to IVA. > >>>>>>>> > >>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to > >>>>>>>> give the > >>>>>>> KMC a > >>>>>>>> command, but the interrupt is going to the wrong vector since > >>>>>>>> RDYI is not > >>>>>>> set. > >>>>>>>> So either you're generating an IVA but setting the wrong status > >>>>>>>> bit, or generating an Ivb event but not to the right vector. Or > >>>>>>>> perhaps you have > >>>>>>> an > >>>>>>>> overrun - the interrupt has to be cleared when the drive clears > >>>>>>>> the RDx > >>>>>>> bit. > >>>>>>>> The data looks like a DDCMP start, less the CRCs. That > >>>>>>>> indicates that a > >>>>>>> fair bit > >>>>>>>> of stuff is working; this is the data that the -10 provides to > >>>>>>>> the > >>>> KMC. > >>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. > (Header > >>>>>>>> and > >>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control in. > >>>>>>>> CRC errors are reported by control out bits. Since the KMC both > >>>>>>>> adds on transmit and removes/checks on receive, and you are > >>> running > >>>>>>>> over an error- checked transport, you can get away with not > >>>>>>>> simulating this - unless you want to interoperate with an > >>>>>>>> interface that does add the > >>>>>> CRCs. > >>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; > >>>>>>>> you'll die later when transport detects a duplicate DECnet node > >>>> number. > >>>>>>>> This communication may not represent my employer's views, if > >>>>>>>> any, on the matters discussed. > >>>>>>>> > >>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: > >>>>>>>>> What is curious now is that I have two instances (identical > >>>>>>>>> clones) > >>>>>>> running > >>>>>>>>> attempting to talk to each other. The first message one sends > >>>>>>>>> to the > >>>>>>> other > >>>>>>>>> crashes the OS: > >>>>>>>>> > >>>>>>>>> ********** > >>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: > >>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 > >>>>>>>>> ********** > >>>>>>>>> > >>>>>>>>> The odd thing is that I have delivered the same data that was > >>>>>>>>> sent from > >>>>>>> the > >>>>>>>>> other end, so it should be valid data. > >>>>>>>>> > >>>>>>>>> The data is: 05 06 C0 00 00 01 > >>>>>>>>> > >>>>>>>>> That data does not seem to completely match the DDCMP spec I > >>> have, > >>>>>>>>> I > >>>>>>>> think > >>>>>>>>> some checksum is supposed to follow. Is that supposed to be > >>>>>>>>> added by the > >>>>>>>> KMC > >>>>>>>>> perhaps? > >>>>>>>>> > >>>>>>>>> I don't fully expect it to work because they are clones so > >>>>>>>>> would expect > >>>>>>>> some > >>>>>>>>> kind of error, but would not expect a crash, or am I wrong? > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Rob > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>> bounces at trailing- > >>>>>>>>>> edge.com] On Behalf Of Robert Jarratt > >>>>>>>>>> Sent: 19 May 2013 15:21 > >>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com > >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>> > >>>>>>>>>> I have made some progress. I realised that I did not have the > >>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is > >>>>>>>>>> working a bit better > >>>>>>>>> now. > >>>>>>>>>> I have indeed seen some commands to read the ram and verify > >>>>>>>>>> the microcode, it does all this to check the KMC is working > >>>>>>>>>> before enabling > >>>>>>>>> it. > >>>>>>>>>> This particular code has never (as far as I know) worked for > >>>>>>>>>> the > >>>>>>>>>> 11 or > >>>>>>> the > >>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working > >>>>>>>>>> with now came from someone else and was written for the > >> PDP1) > >>> for > >>>>>>>>>> a > >>>>>> much > >>>>>>>>>> older version of SIMH. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> > >>>>>>>>>> Rob > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: simh-bounces at trailing-edge.com > >>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of > >> Timothe > >>>>>>>>>>> Litt > >>>>>>>>>>> Sent: 19 May 2013 14:54 > >>>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? > >>>>>>>>>>> > >>>>>>>>>>>> I am pretty sure I am doing all the things you mention > >>>>>>>>>>>> already > >>>>>>>>>>> Then I need a trace of what's happening to the registers, and > >>>>>>>>>>> what > >>>>>>> simh > >>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest > > to > >>>>>>> follow > >>>>>>>>>>> if you output both octal and decode the register > >>>>>>>>>>> names/fields, though I > >>>>>>>>>> can > >>>>>>>>>>> still think - slowly- in octal.) > >>>>>>>>>>> > >>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If > >>>>>>>>>>> so, the basics > >>>>>>>>>> must > >>>>>>>>>>> be OK, though the drivers may well take a different approach > >>>>>>>>>>> to the > >>>>>>>>>> device. > >>>>>>>>>>> Received data should produce either a control-out (error, e.g. > >>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out > >>>>>>>>>>> B > >>>>> interrupt. > >>>>>>>>>>> The > >>>>>>>>>> message > >>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... > >>>>>>>>>>> > >>>>>>>>>>> Transmit done - also note that we ignore interrupts unless > >>>>>>>>>>> the 'last > >>>>>>>>>> buffer' bit > >>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, > >>>>>>>>>>> and require two interrupts.) > >>>>>>>>>>> > >>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is > >>>>>>>>>>> code in the > >>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step > >>> (KMCSUP > >>>>>>>>>>> 400) > >>>>>>>> to > >>>>>>>>>>> force the microcontroller to execute several known > >>>>>>>>>>> instructions > >>>>>>>>>>> - to > >>>>>>>>>> access its > >>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a > >>>>>>>>>>> KMC that halts > >>>>>>>>>> - it > >>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. > >>>>>>>>>>> But some of these are also used to verify data ram at > >> initialization. > >>>>>>>>>>> Failure to > >>>>>>>>>> verify will > >>>>>>>>>>> cause the device to be disabled. We can go down that path if > >>>>>>>>>>> you see > >>>>>>>>>> those > >>>>>>>>>>> bits being set in a trace. > >>>>>>>>>>> > >>>>>>>>>>> Look for KMCXCT calls in > >>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- > >>>>>>>>>>> sources/kdpsrv.mac.html > >>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined > >>>>>>>>>>> in > >>>>>>>>>>> http://bitsavers.trailing- > >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- > KMC11- > >>> OP- > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma > >>>>>>>>>>> nual.pdf > >>>>>>>>>>> >>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- > KMC11- > >>> OP- > >> > PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 > >>>>>>>>>>> 0Manual.pdf> > >>>>>>>>>>> The subset is pretty small - load address register, > >>>>>>>>>>> load/store indirect > >>>>>>>>>> (with > >>>>>>>>>>> increment), & branch. I think you ought to be able to crash > >>>>>>>>>>> simh if an unknown instruction is forced, including a branch > >>>>>>>>>>> to an address other than > >>>>>>>>>> 0. > >>>>>>>>>>> Ugly device, ugly driver. Sigh. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This communication may not represent my employer's views, > if > >>>>>>>>>>> any, on the matters discussed. > >>>>>>>>>>> > >>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: > >>>>>>>>>>>> Thanks Timothe, > >>>>>>>>>>>> > >>>>>>>>>>>> I am pretty sure I am doing all the things you mention > >>>>>>>>>>>> already (sorry I didn't make that clear), but I will check > >>>>>>>>>>>> through everything you have said, just in case I have missed > >> something. > >>>>>>>>>>>> Regards > >>>>>>>>>>>> > >>>>>>>>>>>> Rob > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>> bounces at trailing- > >>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt > >>>>>>>>>>>>> Sent: 19 May 2013 11:26 > >>>>>>>>>>>>> To: simh at trailing-edge.com > >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > Code? > >>>>>>>>>>>>> > >>>>>>>>>>>>> A couple of other things come to mind (naturally, after > >>>>>>>>>>>>> pushing > >>>>>>>>>> 'send'): > >>>>>>>>>>>>> Initialization will load/verify the microcode. That has to > >>>> work. > >>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base- > in > >>>>>>>>>>>>> and control-in command to establish the DUP CSR address, > >>>>>>>>>>>>> buffers, line > >>>>>>>>>>> mode/enable. > >>>>>>>>>>>>> These require that the KMC respond to KMCRQI by > initiating > >>>>>>>>>>>>> an A vector interrupt. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set > >>>>>>>>>>>>> (BSIO) and bit > >>>>>>>>>>>> clear > >>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. > >>>>>>>>>>>>> > >>>>>>>>>>>>> For better directed hints, I'd need more detail on what is > >>>>>>>>>>>>> and isn't > >>>>>>>>>>>> happening. > >>>>>>>>>>>>> This communication may not represent my employer's > views, > >>>>>>>>>>>>> if any, on the matters discussed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- > >>>>>>>>>>> bounces at trailing- > >>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson > >>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 > >>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com > >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver > >>> Code? > >>>>>>>>>>>>>>>> From: "Robert Jarratt" > >>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point > >> me > >>> at > >>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the > >>> KMC11? > >>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to > >>>>>>>>>>>>>>>> do something and read back some values, but I don't > >> know > >>> what > >>>>>>>>>>>>>>>> values it wants to get and so it reports: > >>>>>>>>>>>>>>> Hi, Rob, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://pdp-10.trailing- > >>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm > >>>>>>>>>>>>>>> l > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Rich > >>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP > >>>>> emulation > >>>>>>>>>>> working > >>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one > >>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC > >>>>>>>>>>>>>> has processed a > >>>>>>>>> buffer. > >>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have > >>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt > >>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am > >>> wondering > >>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 > >>>> (decimal). > >>>>>>>>>>>>>> I am not sure how to find out which bit I should be setting. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Can anyone help? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Rob > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >> _______________________________________________ > >>>>>>>>>>>>>> Simh mailing list > >>>>>>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Simh mailing list > >>>>>>>>>> Simh at trailing-edge.com > >>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh > >> > >> _______________________________________________ > >> Simh mailing list > >> Simh at trailing-edge.com > >> http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Mon May 27 08:22:57 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 08:22:57 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> Message-ID: <51A35021.40300@ieee.org> Inline. This communication may not represent my employer's views, if any, on the matters discussed. 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... Map_WriteB() isn't clearing the 4 MBZ bits either. M[pa10] = (M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]; should be: M[pa10] = ((M[pa10] & ~(mask << ubashf[ba & 3])) | (((d10) *buf++) << ubashf[ba & 3]) & ~INT64_C(0600000600000)); Looks like Map_WriteW() cloned it. Ideally, Map_WriteW() should take a (16-bit) word count rather than a byte count. That would simplify life for the code and callers alike. But the VAX UBA routines have the same prototype, so I guess we're stuck with it. A more correct fix would be something like the following (but they still should only check the map on page boundaries, which I'm too lazy to code right now). I haven't compiled this, but I think the logic is correct. # Here we optionally allow return of the map entry a10 Map_Addr10 (a10 ba, int32 ub, int32 *ubm) { a10 pa10; int32 vpn = PAG_GETVPN (ba >> 2); /* get PDP-10 page number */ if ((vpn >= UMAP_MEMSIZE) || (ba & XBA_MBZ) || /* invalid map? */ ((ubmap[ub][vpn] & UMAP_VLD) == 0)) return -1; pa10 = (ubmap[ub][vpn] + PAG_GETOFF (ba >> 2)) & PAMASK; if (ubm) *ubm = ubmap[ub][vpn]; /* Return map entry if requested */ return pa10; } /* The next 5 routines would be more efficient if they only called Map_Addr10 for the first transfer & when crossing a page. */ # pass NULL to Map_addr10. No other changes. int32 Map_ReadB (uint32 ba, int32 bc, uint8 *buf) ... pa10 = Map_Addr10 (ba, 1, NULL); ... int32 Map_ReadW (uint32 ba, int32 bc, uint8 *buf) ... pa10 = Map_Addr10 (ba, 1, NULL); ... #replace existing routines - these should correctly handle UB<17:16> /* Byte-mode writes */ int32 Map_WriteB (uint32 ba, int32 bc, uint8 *buf) { uint32 lim; a10 pa10; d10 mask; lim = ba + bc; for ( ; ba < lim; ba++) { /* by bytes */ pa10 = Map_Addr10 (ba, 1, NULL); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } if( (ba&3) == 0 ) { /* byte 0 writes memory; other bytes & <0:1,18:19> of M[] are undefined. */ M[pa10] = ((d10) *buf++) << 18; /* Clears undefined bits */ } else { /* RPW - clear byte position, and UB<17:16> of correct 1/2 word when writing high byte */ mask = 0377<< ubashf[ba & 3]; if (ba & 1) mask |= INT64_C(0000000600000) << ((ba & 2)? 0 : 18); M[pa10] = (M[pa10] & ~mask) | (((d10) *buf++) << ubashf[ba & 3]); } } return 0; } /* Word mode writes; 16-bit data */ int32 Map_WriteW (uint32 ba, int32 bc, uint16 *buf) { uint32 lim; uint32 ubm; a10 pa10; d10 val; ba = ba & ~01; /* align start */ lim = ba + (bc & ~01); for ( ; ba < lim; ba+= 2) { /* by words */ pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } val = *buf++; /* get 16-bit data, clearing <17:16> */ if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18); } else { if (ba & 2) /* Write odd preserves even word */ M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = val << 18; /* Write even clears odd * } return 0; } # new (unused) routine for 18-bit devices. Identical, except input is 18 bits (in 32 bits). /* Word mode writes; 18-bit data */ int32 Map_WriteW18 (uint32 ba, int32 bc, uint32 *buf) { uint32 lim; uint32 ubm; a10 pa10; d10 val; ba = ba & ~01; /* align start */ lim = ba + (bc & ~01); for ( ; ba < lim; ba+= 2) { /* by words */ pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */ if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */ ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */ return (lim - ba); /* return bc */ } val = *buf++; /* get 18-bit data */ if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18); } else { /* Write odd preserves even word */ if (ba & 2) M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val; else M[pa10] = val << 18; /* Write even clears odd */ } return 0; } >> TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing >> the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when >> the buffer is received. This is a paranoia check to see if the KMC is >> returning a buffer that it didn't write to. >> >> Also, the real UBA wouldn't do a read-modify-write on the first 16-bit >> write (unless read-reverse was set in the UBA map entry). It would >> simply write the first word. The odd word is also done as a simple >> write because the UBA saves the even word's data - that's roughly >> equivalent to RMW. (See >> http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM- >> 002_tech_Sep79.pdf >> around page 5-119 for the gory details, including other transfer modes.) >> >> Third: The additional data in the bugchk is the 10-side view of the >> buffer's first two 36-bit words. This is not the correct data. Note >> that 3 16-bit words are written, which corresponds to your 6 bytes. But >> the data is the same (0746314) in each word. The unwritten word is >> 0777777, which is a good sign that the mapping is correct (though not >> what a real UBA would do). If we clear the two high bits of the data, >> we get 0146314, which is 0xCCcc. >> >> 0xcc happens to be the low byte of the last DMA UB WRITE's address. >> Perhaps the address and data arguments to your unibus_write routine are >> swapped? > This bit had me stumped until I really checked what was going on in > Map_WriteW. I think there is a bug in it on this line: > > for ( ; ba < lim; ba++) { /* by bytes */ > > It should be > > for ( ; ba < lim; ba += 2) { /* by bytes */ > > That is why 0xCCCC was getting written to the memory. Now I can see that the > right data gets into the OS because I temporarily provoked the bugchk again > by not clearing the bits, the additional data looked correct this time. > > However, I still see one end repeatedly sending the first DDCMP message (05 > 06 C0 00 00 01), but nothing else happens, no response going the other way, > no messages on the console etc. I notice that I do get this message on > bootup though: > > SJ 3: $RUN SYS:NETCON > SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246 > SJ 2: ?UNDEFINED OPERATION CODE > SJ 3: > SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY > > Could it be that I still don't have the right version of DECnet on this > virtual machine? > > Thanks! > > Rob > This I'd need to debug on the -10 side. I suspect it's a JSYS failure. Wild guess: NETCON isn't running with correct privileges? > >> You might want to look at pdp10_tu.c for a more efficient way of doing >> large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive >> unibus mapping only once per page, and writes directly to -10 memory - >> bypassing the bug in Map_WriteW. It also handles NXM reporting, which >> hopefully the caller to your interface code is doing... > > It looks like rather than patch Map_WriteW above it would be better to write > a couple of general DMA routines for transferring large buffers. I will try > to do that, let's see if I understand everything you and Rob Doyle have > said.... Probably can take what I supplied above and simply call Map_Addr10 before the for loops, then update when ba crosses a page boundary. The existing routines should handle large buffers if you do that. > >> Note, though, that the tu works thru a RH11, which is an 18-bit device >> and the tape is packing bytes into 36-bit words in odd ways. Don't let >> that confuse you. >> >> Yes, KDPSRV will always return the same buffers; that's expected. It has >> statically allocated buffers for each line's transmit and receive and >> copies data in and out. This is partly due to byte re-ordering and >> partly a matter of simplifying UBA mapping register management. >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> On 26-May-13 04:09, Robert Jarratt wrote: >>> Tim, >>> >>> I have been looking very closely at how I am writing to the memory and I >>> cannot see anything obviously wrong. Let me run you through one receive >>> buffer transfer with some extracts from the log, see if you can spot any >>> flaws: >>> >>> On startup I get two receive buffers as follows: >>> >>> DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710 >> sel6=020000 >>> DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal) >>> DBG(285632654)> KMC CMD: Descriptor for rx buffer: >>> DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal) >>> DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor >>> address=0x93C8(111710 octal) >>> >>> DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530 >> sel6=020000 >>> DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal) >>> DBG(285632752)> KMC CMD: Descriptor for rx buffer: >>> DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal) >>> DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor >>> address=0x9558(112530 octal) >>> >>> A little while later I receive the 6 bytes of data from the peer: >>> >>> DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01 >>> DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal). >> Descriptor >>> is: >>> DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal) >>> DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal) >>> DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal) >>> DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to >> address=0x93D8(111730 >>> octal), bytes=6 >>> dma ub write 0x000093d8=003005(oct) >>> dma ub write 0x000093da=000300(oct) >>> dma ub write 0x000093dc=000400(oct) >>> dma ub write 0x000093cc=101400(oct) >>> >>> So the memory appears to get written correctly to the correct location. > I >>> then transfer the buffer out to the OS using an output command (no >> detailed >>> trace for that), this is immediately followed by me receiving a new > receive >>> buffer (the very one I just sent, so I think the output transfer must > have >>> worked) and the error from the OS: >>> >>> DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710 >> sel6=020000 >>> DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal) >>> DBG(582051478)> KMC CMD: Descriptor for rx buffer: >>> DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal) >>> DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal) >>> DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal) >>> DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor >>> address=0x93C8(111710 octal) >>> >>> ******************** >>> *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24 >>> *BAD DDCMP HEADER >>> *ADDITIONAL DATA: 746314746314, 746314777777 >>> ******************** >>> >>> My suspicion fell on the code to write the data to the memory, this is > the >>> unibus_write code: >>> >>> extern t_stat unibus_write(int32 data, int32 addr) >>> { >>> uint16 d; >>> >>> d = data & 0xFFFF; >>> >>> return Map_WriteW (addr, 2, &d); >>> } >>> >>> Which looks OK to me. >>> >>> Regards >>> >>> Rob >>> >>>> -----Original Message----- >>>> From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing- >>>> edge.com] On Behalf Of Robert Jarratt >>>> Sent: 19 May 2013 22:47 >>>> To: 'Timothe Litt' >>>> Cc: simh at trailing-edge.com >>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>> >>>> Thanks, that sounds likely, I will check how I am writing to memory. >>>> >>>> Regards >>>> >>>> Rob >>>> >>>>> -----Original Message----- >>>>> From: Timothe Litt [mailto:litt at ieee.org] >>>>> Sent: 19 May 2013 21:41 >>>>> To: Robert Jarratt >>>>> Cc: simh at trailing-edge.com >>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>> >>>>> This is progress. Looks to me like the data isn't being stored >>> properly. >>>>> The ADDITIONAL DATA is the first 8 bytes of the data buffer. The >>>>> SKIPL says the sign bit is set (which it is in 7463...). >>>>> That's not possible. >>>>> >>>>> So I suspect you're not writing the data thru the UBA map correctly. >>>>> >>>>> Data from the UBA in -10 memory is in PDP-11 byte order, with 16 bit >>>>> words packed into 18-bit 1/2 words. >>>>> This looks like: >>>>> >>>>> /-- Bit 0 - the sign bit tested by the SKIPL & SKIPGE >>>>> / /-- The ENQ goes here >>>>> / / -- The START goes here >>>>> ! 00 ! byte 1 ! byte 0 ! 00 ! byte 3 ! byte 2 ! < PDP-10 word 0 ! 00 ! >>>>> byte 5 ! byte 4 ! 00 ! byte 7 ! byte 6 ! < PDP-10 word 1 >>>>> >>>>> Since 00 is constant, the first digit can't be > 1. 7 mumble is. >>>>> >>>>> Thus for 05 06 (ENQ START), we should see something like 3005,,... in >>>>> the first word. >>>>> (5 + 6 << 8) >>>>> >>>>> Also, you need to map the UBA address to PDP-10 memory (which you >>>> seem >>>>> to be doing for reads). >>>>> >>>>> >>>>> This communication may not represent my employer's views, if any, on >>>>> the matters discussed. >>>>> >>>>> On 19-May-13 16:06, Robert Jarratt wrote: >>>>>> Oops, meant to say the first byte sent is 0x05. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com] >>>>>>> Sent: 19 May 2013 21:01 >>>>>>> To: 'Timothe Litt'; 'simh at trailing-edge.com' >>>>>>> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>> >>>>>>> Thanks! There was a bug in my interrupt acknowledge routine. With >>>>>>> that fixed the interrupts now seem to be working OK. I have made >>>>>>> progress, >>>>> with >>>>>>> the two clones talking to each other I get this now: >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> *BUGCHK "BADHDR" AT 19-MAY-2013 20:40:52 >>>>>>> *BAD DDCMP HEADER >>>>>>> *ADDITIONAL DATA: 746314746314, 746314777777 >>>>>>> ******************** >>>>>>> >>>>>>> I am going to have to re-learn MACRO to work out why it is failing. >>>>>>> The >>>>>> code I >>>>>>> see has two jumps to BUMHDR, I can't work out what the first one >>>>>>> means, the second seems to be checking the first byte, which being >>>>>>> 0x06 should >>>>> be >>>>>>> OK, so it is probably the first condition that is failing. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of Timothe Litt >>>>>>>> Sent: 19 May 2013 18:01 >>>>>>>> To: simh at trailing-edge.com >>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>> >>>>>>>> That's the code that emitted the bugcheck. BUG(KMCIII) => >> BUGHLT >>>>>>>> "KMCIII". >>>>>>>> >>>>>>>> You need to tell simh what vector to use when you tell it about >>>>>>>> the pending interrupt. Most devices have only one vector. The KMC >>>> (and >>>>>>>> DMC/DMR) have 2. A is the (numerically) first; B is the second. >>> So >>>> in >>>>>>>> the interrupt ack routine, you need to return VEC_KDP * >> kmcnumber >>>>>>>> or VEC_KDP * kmcnumber +4, depending on which interrupt is being >>>>> granted. >>>>>>>> (Or whatever symbol you used.) A should be generated by RDI; B by >>>>> RDO. >>>>>>>> That will tell simh how to find the right service routine. >>>>>>>> >>>>>>>> IIRC, if both happen to be pending at the same time, A takes >>>>> precedence. >>>>>>>> Without seeing the code, I can't be more explicit... >>>>>>>> >>>>>>>> Oh, be careful when you talk about bit numbers. The unibus is >>>>>>>> little-endian (lsb = bit 0); the -10 is big-endian (MSB -0 bit 0). >>>>>>>> >>>>>>>> This communication may not represent my employer's views, if any, >>>>>>>> on the matters discussed. >>>>>>>> >>>>>>>> On 19-May-13 12:36, Robert Jarratt wrote: >>>>>>>>> Hmmm.... I do have RDYO set, but it is supposed to be a B >>>>>>>>> interrupt, not an A, so that would make sense. I have A vectored >>>>>>>>> at bit 8, and B at bit >>>>>>>> 9. >>>>>>>>> Are you referring to this code: >>>>>>>>> >>>>>>>>> ;HERE FOR INPUT INTERRUPTS >>>>>>>>> KMCVCA: MOVEM 17,KMCACS+17 ;SAVE REG >>>>>>>>> MOVEI 17,KMCACS ;BUILD BLT POINTER >>>>>>>>> BLT 17,KMCACS+16 ;SAVE REST OF REGS >>>>>>>>> MOVE P,[-40,,KMCIPL] ;SET UP STACK >>>>>>>>> MOVE T4,[KMCADR] ;GET ADDRESS OF THE KMC11 HDW >>>>>>>>> RDIO T2,BSEL2(T4) ;GET RDI FLAG >>>>>>>>> MOVE T1,KMCINQ+1 ;GET INPUT QUEUE TAKER >>>>>>>>> CAME T1,KMCINQ ;ARE PUTTER AND TAKE >> DIFFERENT ? >>>>>>>>> TRNN T2,KMCRDI ;AND IS IT READY ? >>>>>>>>> BUG (KMCIII,<,>) << A interrupt with nothing >> in >>> the >>>>>>>> driver queue, or RDI not set >>>>>>>>> CAIN T1,KMCINQ+KMCQLN-1 ;TIME TO WRAP AROUND >> AGAIN ? >>>>>>>>> MOVEI T1,KMCINQ+1 ;YES SO POINT TO BEGINING OF >> QUEUE >>>>>>>>> ADDI T1,2 ;ADVANCE POINTER FOR THIS ENTRY >>>>>>>>> MOVEM T1,KMCINQ+1 ;SAVE UPDATED TAKER >>>>>>>>> MOVEI T2,KMCRQI ;WANT TO CLEAR RQUEST >> INPUT >>>>>>>> FLAG << CSR BIT requesting an A interrupt >>>>>>>>> CAMN T1,KMCINQ ;IS QUEUE EMPTY NOW ? >>>>>>>>> BCIO T2,BSEL0(T4) ;THIS IS LAST OF DATA << Clears >>> request >>>>>>>> when driver queue empty >>>>>>>>> MOVE T2,(T1) ;GET 2ND WORD IN QUEUE ENTRY >>>>>>>>> MOVE T1,-1(T1) ;GET 1ST WORD IN QUEUE >> ENTRY >>>>>>>>> << the command is then removed from the driver queue and >> written >>>>> to >>>>>>>>> the KMC. The KMC >>>>>>>> << must clear RDI until it is ready to take the next command. >>>>>>>> (Note that otherwise if the queue depth >1, the << A interrupt >>>>>>>> will happen immediately. >>>>>>>>> If so, then despite the fact that I am setting bit 9 in the >>>>>>>>> interrupt request, it seems to be going to the A interrupt > handler. >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Rob >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>> bounces at trailing- >>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>> Sent: 19 May 2013 17:01 >>>>>>>>>> Cc: simh at trailing-edge.com >>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>> >>>>>>>>>> The bugcheck is saying that the RDYO is set, but not RDYI on an >>>>>>>>>> A >>>>>>>>> interrupt. >>>>>>>>>> (KMCRDI is 20; RDO is 200) >>>>>>>>>> >>>>>>>>>> RDYO should always go to IVB; RDYI to IVA. >>>>>>>>>> >>>>>>>>>> Since we took an IVA interrupt, the driver thinks its trying to >>>>>>>>>> give the >>>>>>>>> KMC a >>>>>>>>>> command, but the interrupt is going to the wrong vector since >>>>>>>>>> RDYI is not >>>>>>>>> set. >>>>>>>>>> So either you're generating an IVA but setting the wrong status >>>>>>>>>> bit, or generating an Ivb event but not to the right vector. Or >>>>>>>>>> perhaps you have >>>>>>>>> an >>>>>>>>>> overrun - the interrupt has to be cleared when the drive clears >>>>>>>>>> the RDx >>>>>>>>> bit. >>>>>>>>>> The data looks like a DDCMP start, less the CRCs. That >>>>>>>>>> indicates that a >>>>>>>>> fair bit >>>>>>>>>> of stuff is working; this is the data that the -10 provides to >>>>>>>>>> the >>>>>> KMC. >>>>>>>>>> Yes, the KMC is supposed to add (and check) the CRC-16s. >> (Header >>>>>>>>>> and >>>>>>>>>> data) - unless CRC inhibit (1000) is set in BSEL6 by a control > in. >>>>>>>>>> CRC errors are reported by control out bits. Since the KMC both >>>>>>>>>> adds on transmit and removes/checks on receive, and you are >>>>> running >>>>>>>>>> over an error- checked transport, you can get away with not >>>>>>>>>> simulating this - unless you want to interoperate with an >>>>>>>>>> interface that does add the >>>>>>>> CRCs. >>>>>>>>>> Even if the systems are cloned, the DDCMP layer should come up; >>>>>>>>>> you'll die later when transport detects a duplicate DECnet node >>>>>> number. >>>>>>>>>> This communication may not represent my employer's views, if >>>>>>>>>> any, on the matters discussed. >>>>>>>>>> >>>>>>>>>> On 19-May-13 11:01, Robert Jarratt wrote: >>>>>>>>>>> What is curious now is that I have two instances (identical >>>>>>>>>>> clones) >>>>>>>>> running >>>>>>>>>>> attempting to talk to each other. The first message one sends >>>>>>>>>>> to the >>>>>>>>> other >>>>>>>>>>> crashes the OS: >>>>>>>>>>> >>>>>>>>>>> ********** >>>>>>>>>>> *BUGHLT "KMCIII" AT 19-May-2013 15: >>>>>>>>>>> *ADDITIONAL DATA: 000000172507, 000000000200 >>>>>>>>>>> ********** >>>>>>>>>>> >>>>>>>>>>> The odd thing is that I have delivered the same data that was >>>>>>>>>>> sent from >>>>>>>>> the >>>>>>>>>>> other end, so it should be valid data. >>>>>>>>>>> >>>>>>>>>>> The data is: 05 06 C0 00 00 01 >>>>>>>>>>> >>>>>>>>>>> That data does not seem to completely match the DDCMP spec I >>>>> have, >>>>>>>>>>> I >>>>>>>>>> think >>>>>>>>>>> some checksum is supposed to follow. Is that supposed to be >>>>>>>>>>> added by the >>>>>>>>>> KMC >>>>>>>>>>> perhaps? >>>>>>>>>>> >>>>>>>>>>> I don't fully expect it to work because they are clones so >>>>>>>>>>> would expect >>>>>>>>>> some >>>>>>>>>>> kind of error, but would not expect a crash, or am I wrong? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Rob >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>> bounces at trailing- >>>>>>>>>>>> edge.com] On Behalf Of Robert Jarratt >>>>>>>>>>>> Sent: 19 May 2013 15:21 >>>>>>>>>>>> To: 'Timothe Litt'; simh at trailing-edge.com >>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>> >>>>>>>>>>>> I have made some progress. I realised that I did not have the >>>>>>>>>>>> interrupt acknowledgement routines set up in the DIB. It is >>>>>>>>>>>> working a bit better >>>>>>>>>>> now. >>>>>>>>>>>> I have indeed seen some commands to read the ram and verify >>>>>>>>>>>> the microcode, it does all this to check the KMC is working >>>>>>>>>>>> before enabling >>>>>>>>>>> it. >>>>>>>>>>>> This particular code has never (as far as I know) worked for >>>>>>>>>>>> the >>>>>>>>>>>> 11 or >>>>>>>>> the >>>>>>>>>>>> VAX. I wrote the DMC11 code for those. This code I am working >>>>>>>>>>>> with now came from someone else and was written for the >>>> PDP1) >>>>> for >>>>>>>>>>>> a >>>>>>>> much >>>>>>>>>>>> older version of SIMH. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: simh-bounces at trailing-edge.com >>>>>>>>>>>>> [mailto:simh-bounces at trailing- edge.com] On Behalf Of >>>> Timothe >>>>>>>>>>>>> Litt >>>>>>>>>>>>> Sent: 19 May 2013 14:54 >>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code? >>>>>>>>>>>>> >>>>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>>>> already >>>>>>>>>>>>> Then I need a trace of what's happening to the registers, and >>>>>>>>>>>>> what >>>>>>>>> simh >>>>>>>>>>>>> thinks it's doing with the interrupts. (It would be easiest >>> to >>>>>>>>> follow >>>>>>>>>>>>> if you output both octal and decode the register >>>>>>>>>>>>> names/fields, though I >>>>>>>>>>>> can >>>>>>>>>>>>> still think - slowly- in octal.) >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I thought this code was working for the -11/VAX. If >>>>>>>>>>>>> so, the basics >>>>>>>>>>>> must >>>>>>>>>>>>> be OK, though the drivers may well take a different approach >>>>>>>>>>>>> to the >>>>>>>>>>>> device. >>>>>>>>>>>>> Received data should produce either a control-out (error, e.g. >>>>>>>>>>>>> no buffer available or DSR change or NXM...) or a buffer-out >>>>>>>>>>>>> B >>>>>>> interrupt. >>>>>>>>>>>>> The >>>>>>>>>>>> message >>>>>>>>>>>>> must fit in 1 buffer. Errors may implicitly free a BDL... >>>>>>>>>>>>> >>>>>>>>>>>>> Transmit done - also note that we ignore interrupts unless >>>>>>>>>>>>> the 'last >>>>>>>>>>>> buffer' bit >>>>>>>>>>>>> is set. (The DDCMP header and data are in two BDL segments, >>>>>>>>>>>>> and require two interrupts.) >>>>>>>>>>>>> >>>>>>>>>>>>> Finally, I'm not sure if you'll see it used, but there is >>>>>>>>>>>>> code in the >>>>>>>>>>>>> TOPS-20 driver that uses KMCRMI (1000 in BSEL0) & step >>>>> (KMCSUP >>>>>>>>>>>>> 400) >>>>>>>>>> to >>>>>>>>>>>>> force the microcontroller to execute several known >>>>>>>>>>>>> instructions >>>>>>>>>>>>> - to >>>>>>>>>>>> access its >>>>>>>>>>>>> data ram, registers & PC. This is primarily used to dump a >>>>>>>>>>>>> KMC that halts >>>>>>>>>>>> - it >>>>>>>>>>>>> doesn't seem to be used when the built-in ucode is loaded. >>>>>>>>>>>>> But some of these are also used to verify data ram at >>>> initialization. >>>>>>>>>>>>> Failure to >>>>>>>>>>>> verify will >>>>>>>>>>>>> cause the device to be disabled. We can go down that path if >>>>>>>>>>>>> you see >>>>>>>>>>>> those >>>>>>>>>>>>> bits being set in a trace. >>>>>>>>>>>>> >>>>>>>>>>>>> Look for KMCXCT calls in >>>>>>>>>>>>> http://pdp-10.trailing-edge.com/BB-Y393K-SM/01/monitor- >>>>>>>>>>>>> sources/kdpsrv.mac.html >>>>>>>>>>>>> TOPS-10 doesn't do this. The microinstructions are defined >>>>>>>>>>>>> in >>>>>>>>>>>>> http://bitsavers.trailing- >>>>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- >> KMC11- >>>>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User's%20Ma >>>>>>>>>>>>> nual.pdf >>>>>>>>>>>>> >>>>>>>>>>>> edge.com/www.computer.museum.uq.edu.au/pdf/EK- >> KMC11- >>>>> OP- >> PRE%20KMC11%20General%20Purpose%20Microprocessor%20User%27s%2 >>>>>>>>>>>>> 0Manual.pdf> >>>>>>>>>>>>> The subset is pretty small - load address register, >>>>>>>>>>>>> load/store indirect >>>>>>>>>>>> (with >>>>>>>>>>>>> increment), & branch. I think you ought to be able to crash >>>>>>>>>>>>> simh if an unknown instruction is forced, including a branch >>>>>>>>>>>>> to an address other than >>>>>>>>>>>> 0. >>>>>>>>>>>>> Ugly device, ugly driver. Sigh. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This communication may not represent my employer's views, >> if >>>>>>>>>>>>> any, on the matters discussed. >>>>>>>>>>>>> >>>>>>>>>>>>> On 19-May-13 07:42, Robert Jarratt wrote: >>>>>>>>>>>>>> Thanks Timothe, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am pretty sure I am doing all the things you mention >>>>>>>>>>>>>> already (sorry I didn't make that clear), but I will check >>>>>>>>>>>>>> through everything you have said, just in case I have missed >>>> something. >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>> edge.com] On Behalf Of Timothe Litt >>>>>>>>>>>>>>> Sent: 19 May 2013 11:26 >>>>>>>>>>>>>>> To: simh at trailing-edge.com >>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >> Code? >>>>>>>>>>>>>>> A couple of other things come to mind (naturally, after >>>>>>>>>>>>>>> pushing >>>>>>>>>>>> 'send'): >>>>>>>>>>>>>>> Initialization will load/verify the microcode. That has to >>>>>> work. >>>>>>>>>>>>>>> After setting RUN and the interrupt enables, expect base- >> in >>>>>>>>>>>>>>> and control-in command to establish the DUP CSR address, >>>>>>>>>>>>>>> buffers, line >>>>>>>>>>>>> mode/enable. >>>>>>>>>>>>>>> These require that the KMC respond to KMCRQI by >> initiating >>>>>>>>>>>>>>> an A vector interrupt. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Besides RDIO and WRIO, there are bit test (TIOx) , bit set >>>>>>>>>>>>>>> (BSIO) and bit >>>>>>>>>>>>>> clear >>>>>>>>>>>>>>> (BCIO) instructions that also touch the KMC. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For better directed hints, I'd need more detail on what is >>>>>>>>>>>>>>> and isn't >>>>>>>>>>>>>> happening. >>>>>>>>>>>>>>> This communication may not represent my employer's >> views, >>>>>>>>>>>>>>> if any, on the matters discussed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 19-May-13 04:53, Robert Jarratt wrote: >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: simh-bounces at trailing-edge.com [mailto:simh- >>>>>>>>>>>>> bounces at trailing- >>>>>>>>>>>>>>>>> edge.com] On Behalf Of Rich Alderson >>>>>>>>>>>>>>>>> Sent: 08 May 2013 01:02 >>>>>>>>>>>>>>>>> To: hecnet at update.uu.se; simh at trailing-edge.com >>>>>>>>>>>>>>>>> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver >>>>> Code? >>>>>>>>>>>>>>>>>> From: "Robert Jarratt" >>>>>>>>>>>>>>>>>> Date: Tue, 7 May 2013 23:33:36 +0100 Can anyone point >>>> me >>>>> at >>>>>>>>>>>>>>>>>> the right place to look at TOPS-20 driver code for the >>>>> KMC11? >>>>>>>>>>>>>>>>>> I can see that it is trying to get the Microprocessor to >>>>>>>>>>>>>>>>>> do something and read back some values, but I don't >>>> know >>>>> what >>>>>>>>>>>>>>>>>> values it wants to get and so it reports: >>>>>>>>>>>>>>>>> Hi, Rob, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://pdp-10.trailing- >>>>>>>>>>>>> edge.com/tops20v41_monitor_sources/index.htm >>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You want the file KDPSRV.MAC in that directory. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Rich >>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>>>>>> I am making some progress with getting the KMC/DUP >>>>>>> emulation >>>>>>>>>>>>> working >>>>>>>>>>>>>>>> in SIMH for TOPS-20. At the moment I am stuck on one >>>>>>>>>>>>>>>> thing, which is the interrupts to tell the OS that the KMC >>>>>>>>>>>>>>>> has processed a >>>>>>>>>>> buffer. >>>>>>>>>>>>>>>> The OS sets the interrupt enable bit and when I have >>>>>>>>>>>>>>>> something to report to the OS I set the relevant interrupt >>>>>>>>>>>>>>>> bit. However, nothing happens when I do that. I am >>>>> wondering >>>>>>>>>>>>>>>> if I have the right interrupt bit? I am using bits 8 and 9 >>>>>> (decimal). >>>>>>>>>>>>>>>> I am not sure how to find out which bit I should be > setting. >>>>>>>>>>>>>>>> Can anyone help? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rob >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>>>>>>> Simh mailing list >>>>>>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Simh mailing list >>>>>>>>>>>> Simh at trailing-edge.com >>>>>>>>>>>> http://mailman.trailing-edge.com/mailman/listinfo/simh >>>> _______________________________________________ >>>> Simh mailing list >>>> Simh at trailing-edge.com >>>> http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 08:37:25 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 05:37:25 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A35021.40300@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> 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 From litt at ieee.org Mon May 27 08:49:34 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 08:49:34 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> Message-ID: <51A3565E.1050108@ieee.org> 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: From litt at ieee.org Mon May 27 09:18:06 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:18:06 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> Message-ID: <51A35D0E.8050501@ieee.org> This wouldn't be a -10 coding issue. It worked on the real systems. The CR's data transfer in simh may be broken due to the bugs discussed. But the 'unavailable' status is probably that GALAXY has control of the device and expects to spool data via CDRIVE/SPRINT, which may need to be started. See the operator's and galaxy batch documentation. (e.g. http://www.textfiles.com/bitsavers/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol02/AA_H374B_batch.pdf http://www.textfiles.com/bitsavers/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol17/AA-H599C-TB_OperCmdLang.pdf) One of these days I'll might build a monitor with CDR support and try it. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 08:58, Jordi Guillaumes i Pons wrote: > Just Fyi the CD11 does NOT work in TOPS-10. The OS "sees" the device (it shows in RES) but it is always reported as "unavailable". I have plans to teach myself MACRO-10 and have a look at the driver and the simh code like I did with the CR for the '11 and the VAX, but I can't commit myself on a date to do it (I am having too much fun with DECNET-OSI at this moment). > > Jordi Guillaumes i Pons > Barcelona - Catalunya - Europa > > El 27/05/2013, a les 14:49, Timothe Litt va escriure: >> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 09:19:00 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:19:00 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> Message-ID: <51A35D44.5090601@ieee.org> 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: From robert.jarratt at ntlworld.com Mon May 27 09:32:09 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 14:32:09 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A3565E.1050108@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> Message-ID: <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> I also see a reference in pdp11_hk which is the RK611/RK06/RK07 disk controller Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 27 May 2013 13:50 > To: Mark Pizzolato - Info Comm > Cc: Robert Jarratt; simh at trailing-edge.com > 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: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 > > > From litt at ieee.org Mon May 27 09:34:33 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:34:33 -0400 Subject: [Simh] Netcon In-Reply-To: <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> Message-ID: <51A360E9.3050107@ieee.org> > owever, I still see one end repeatedly sending the first DDCMP message > (05 06 C0 00 00 01), but nothing else happens, no response going the > other way, no messages on the console etc. I notice that I do get this > message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL > INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % > NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still > don't have the right version of DECnet on this virtual machine? > Thanks! Rob Er, are you still running cloned systems? Make sure the node number and name are different between the two. As I wrote, I'd need to debug this, but it's possible that NETCON just isn't graceful about this. This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 09:35:33 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 09:35:33 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <04b701ce5ade$981b7960$c8526c20$@ntlworld.com> Message-ID: <51A36125.3030804@ieee.org> 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:litt at ieee.org] >> Sent: 27 May 2013 13:50 >> To: Mark Pizzolato - Info Comm >> Cc: Robert Jarratt; simh at trailing-edge.com >> 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: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: From litt at ieee.org Mon May 27 10:14:16 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 10:14:16 -0400 Subject: [Simh] Speaking of cards Message-ID: <51A36A38.3060106@ieee.org> Since the CD20 was mentioned, I wondered if there was an 029 emulator available to produce card decks. Haven't found one, but did find http://x3270.bgp.nu/x026.html, which I haven't done much with. It does build on linux and seems to run. It claims to support the 029 character set as well. But it doesn't support drum cards, skip, dup, zero-fill, or anything other than straight typing. Does anyone know of a better emulator? Or know X well enough to feel like adding at least drum card eumlation? https://en.wikipedia.org/wiki/Keypunch documents the drum (or Program) card. I have some blank punch cards, I should scan one as it only comes with some customized images. Does anyone know how to (on windows or Linux) convert a scanned image in a modern format (bmp,jpeg,tiff, etc) to xpm? http://homepage.cs.uiowa.edu/~jones/cards/codes.html has a fair bit of documentation on card formats, including what simh uses. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From aek at bitsavers.org Mon May 27 10:36:19 2013 From: aek at bitsavers.org (Al Kossow) Date: Mon, 27 May 2013 07:36:19 -0700 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: <51A36F63.9050609@bitsavers.org> On 5/27/13 7:14 AM, Timothe Litt wrote: > I have some blank punch cards, I should scan one as it only comes with some customized images. > I can make a high resolution scan of a buff 5081 if it's needed. From tfmorris at gmail.com Mon May 27 10:43:36 2013 From: tfmorris at gmail.com (Tom Morris) Date: Mon, 27 May 2013 10:43:36 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: On Mon, May 27, 2013 at 10:14 AM, Timothe Litt wrote: > > Does anyone know how to (on windows or Linux) convert a scanned image in a > modern format (bmp,jpeg,tiff, etc) to xpm? > ImageMagick supports most formats, including xpm. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfmorris at gmail.com Mon May 27 10:58:34 2013 From: tfmorris at gmail.com (Tom Morris) Date: Mon, 27 May 2013 10:58:34 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A36A38.3060106@ieee.org> References: <51A36A38.3060106@ieee.org> Message-ID: p.s. Love this quote from the card format documentation page On Mon, May 27, 2013 at 10:14 AM, Timothe Litt wrote: > > http://homepage.cs.uiowa.edu/~**jones/cards/codes.html< > http://homepage.cs.uiowa.edu/**%7Ejones/cards/codes.html> > has a fair bit of documentation on card formats, including what simh uses. "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN character set to ASCII. Unfortunately, it appears to have nothing in common with other extensions of the same character set. Given the frequency of typos in DEC's handbooks, it is possible that the problem is with the handbook from which this material was derived." -------------- next part -------------- An HTML attachment was scrubbed... URL: From litt at ieee.org Mon May 27 11:01:22 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 11:01:22 -0400 Subject: [Simh] Speaking of cards In-Reply-To: References: <51A36A38.3060106@ieee.org> Message-ID: <51A37542.60201@ieee.org> > ImageMagick supports most formats, including xpm. > That's way too simple. I even have ImageMagick :-( > I can make a high resolution scan of a buff 5081 if it's needed. I have pink cards for sure...buff wouldn't hurt. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 10:43, Tom Morris wrote: > On Mon, May 27, 2013 at 10:14 AM, Timothe Litt > wrote: > > > Does anyone know how to (on windows or Linux) convert a scanned > image in a modern format (bmp,jpeg,tiff, etc) to xpm? > > > ImageMagick supports most formats, including xpm. > > Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 11:24:43 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 11:24:43 -0400 Subject: [Simh] Speaking of cards In-Reply-To: References: <51A36A38.3060106@ieee.org> Message-ID: <51A37ABB.7000001@ieee.org> Well, TOPS-10 uses this, and our customers were happy. Of course, 029 was much more common in the PDP-10 era. ;THE CHARACTER TRANSLATION TABLES: $HIGH CRCVPT::XWD 350700+T2,CRCVTB XWD 260700+T2,CRCVTB XWD 170700+T2,CRCVTB XWD 100700+T2,CRCVTB ;CODE CONVERSION FOR THE 029 KEYPUNCH ;THE FOLLOWING EQUIVALENCES ARE ARTIFICIALLY DEFINED ;029 KEYTOP ;ASCII 35 ;ASCII 37 ;CENT [ [ ;0-8-2 ] ] ;VERT BAR ^ HAT = L.C. VERT BAR ;UNDERBAR _ UNDERBAR ;NEGATION \ TILDE = L.C. NEGATION ;CHARACTERS ;ZONE/DIGITS CRCVTB: ASCII / 123/ ;N/N-3 ASCII .0/ST. ;0/N-3 ASCII /-JKL/ ;11/N-3 ASCII /HI[./ ;12,8/N-3 ASCII /&ABC/ ;12/N-3 ASCII /QR]$/ ;11,8/N-3 ASCII /YZ\,/ ;0,8/N-3 ASCII /89:#/ ;8/N-3 ASCII /4567/ ;N/4-7 ASCII /UVWX/ ;0/4-7 ASCII /MNOP/ ;11/4-7 ASCII /<(+!/ ;12,8/4-7 ASCII /DEFG/ ;12/4-7 ASCII /*);^/ ;11,8/4-7 ASCII /%_>?/ ;0,8/4-7 ASCII /@'="/ ;8/4-7 ;CODE FOR THE 026 KEYPUNCH A LA H HYMAN ASCII / 123/ ;N/N-3 ASCII .0/ST. ;0/N-3 ASCII /-JKL/ ;11/N-3 ASCII /HI?./ ;12,8/N-3 ASCII /+ABC/ ;12/N-3 ASCII /QR:$/ ;11,8/N-3 ASCII /YZ;,/ ;0,8/N-3 ASCII /89_=/ ;8/N-3 ASCII /4567/ ;N/4-7 ASCII /UVWX/ ;0/4-7 ASCII /MNOP/ ;11/4-7 ASCII /)]&/ ;11,8/4-7 ASCII /("#%/ ;0,8/4-7 ASCII /@^'\/ ;8/4-7 ;HERE IF DATA IS IN ASCII OR BINARY MODE NOTIMG: ILDB U,T3 ;GET COLUMN 1 MOVE T1,U ;SAVE HERE TRZ U,770000 ;JUST COLUMN DATA CAIE U,CODEOF+NEWEOF ;IS IT AN EOF CARD? CAIN U,CODEOF ;OR THIS TYPE? PJRST EOFCRD ;YES--SET FLAGS CAIN U,NEWEOF ;IS IT NEW TYPE EOF? PJRST EOFCRD ;YES--SET FLAGS TRNE S,14 ;BINARY MODE? PJRST CDRBIN ;YES--GO PROCESS IT ;HERE TO PROCESS AN ASCII CARD CAIN U,COD026 ;026 CARD? PJRST SET026 ;YES--SET MODE CAIN U,COD029 ;029 CARD? PJRST SET029 ;YES--SET MODE SKIPA U,T1 ;RESTORE COLUMN 1 AND SKIP NEXT ASCLOP: ILDB U,T3 ;GET NEXT COLUMN TRNE U,100000 ;MULTI-PUNCHED COLUMN? JRST [MOVEI U,"\" ;YES--GET INVALID CHARACTER JRST ASCLO1] ; AND STORE THAT SETZB T1,T2 CAIN U,5000 ;CONVERT "[" MOVEI U,24202 ; TO INTERNAL FORM CAIN U,3000 ;CONVERT "]" MOVEI U,22202 ; TO INTERNAL FORM LDB T2,[POINT 3,U,26] ;GET ZONES PLUS LOW ENCODED BIT TRNE U,3 ;AN 8 OR 9 PUNCH? TRC T2,7 ;YES--ENCODE THAT TRZE U,40000 ;COPY THIS BIT TRO T2,10 ; TO HERE TRNE U,1 ;THIS BIT ON TRO U,10000 ; MEANS THIS BIT SHOULD BE ON LSH U,-^D12 ;POSITION REMAINING CODE BITS TLNE S,CR026 ;026 MODE? TRO T2,20 ;YES--BUMP T2 TO 026 TABLE LDB U,CRCVPT##(U) ;PICK UP ASCII CHAR FROM TABLE ASCLO1: IDPB U,DEVPTR(F) ;PUT INTO USER BUFFER SOJG T4,ASCLOP ;LOOP THRU CARD MOVEI T1,15 ;INSERT IDPB T1,DEVPTR(F) MOVEI T1,12 ;INSERT IDPB T1,DEVPTR(F) PJRST CDRDON ;FINISH UP This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 10:58, Tom Morris wrote: > p.s. Love this quote from the card format documentation page > > > On Mon, May 27, 2013 at 10:14 AM, Timothe Litt > wrote: > > > http://homepage.cs.uiowa.edu/~jones/cards/codes.html > > has a > fair bit of documentation on card formats, including what simh uses. > > > > "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN > character set to ASCII. Unfortunately, it appears to have nothing in > common with other extensions of the same character set. Given the > frequency of typos in DEC's handbooks, it is possible that the problem > is with the handbook from which this material was derived." -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From robert.jarratt at ntlworld.com Mon May 27 11:36:00 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 16:36:00 +0100 Subject: [Simh] Netcon In-Reply-To: <51A360E9.3050107@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> Message-ID: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> The disks are cloned but I modified 4-1-config.cmd to change the node name and number. That is all I did. So in one I have the line NODE TOPS20 25 And in the other I have NODE TOPS21 26 I don't know much about how NETCON would get its permissions, it is being started from SYSJOB.RUN, this is what I have in that file after following the instructions in the manual I was following: RUN SYS:ORION RUN SYS:QUASAR RUN SYS:MOUNTR RUN SYS:INFO RUN SYS:MAILER RUN SYS:MAPPER RUN SYS:LPTSPL RUN SYS:LPTSPL RUN SYS:CDRIVE RUN SYS:SPRINT JOB 0 /LOG OPERATOR XX OPERATOR ENA ^ESET LOGIN PSEUDO ^ESET LOGIN CONSOLE ^ESET OPERATOR PTYCON GET SYSTEM:PTYCON.ATO / JOB 1 /LOG OPERATOR XX OPERATOR ENA RUN SYS:BATCON / JOB 2 /LOG OPERATOR XX OPERATOR ENA RUN SYS:FAL / JOB 3 /LOG OPERATOR XX OPERATOR ENA RUN SYS:NETCON / Note that the manual used "\LOG" rather than "/LOG" but was contradictory on this as in some places it was one and in others it was the other. I tried a loopback test, which failed as per the attached log file. One more data point. When I use UETP to verify the configuration I get these errors in the log: $TYPE EXCEPT.LOG.2 ERROR VF2020 27-May-2013 10:32:24 0:00:00 0:00:00 ? Mismatch occurred during verification: Currently installed file: PS:DECNET.BWR.1 644032 P Correct file: PS:DECNET.BWR.1 556602 P ERROR VF2020 27-May-2013 10:32:24 0:00:00 0:00:00 ? Mismatch occurred during verification: Currently installed file: PS:DECNET.DOC.1 350434 P Correct file: PS:DECNET.DOC.1 614303 P They suggest that the docs are not right, but nothing else. Regards Rob > -----Original Message----- > From: Timothe Litt [mailto:litt at ieee.org] > Sent: 27 May 2013 14:35 > To: Robert Jarratt > Cc: simh at trailing-edge.com > Subject: Re: [Simh] Netcon > > > owever, I still see one end repeatedly sending the first DDCMP message > > (05 06 C0 00 00 01), but nothing else happens, no response going the > > other way, no messages on the console etc. I notice that I do get this > > message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL > > INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % > > NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still > > don't have the right version of DECnet on this virtual machine? > > Thanks! Rob > > Er, are you still running cloned systems? Make sure the node number and > name are different between the two. > > As I wrote, I'd need to debug this, but it's possible that NETCON just > isn't graceful about this. > > > This communication may not represent my employer's views, > if any, on the matters discussed. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dnv2ll.log Type: application/octet-stream Size: 6944 bytes Desc: not available URL: From jg at jordi.guillaumes.name Mon May 27 11:39:20 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 17:39:20 +0200 Subject: [Simh] Fwd: Re: Speaking of cards In-Reply-To: <51A37DC1.4070107@jordi.guillaumes.name> References: <51A37DC1.4070107@jordi.guillaumes.name> Message-ID: <51A37E28.4050408@jordi.guillaumes.name> Brrr... Thunderbird keeps replying to the sender instead of to the list by default... -------- Missatge original -------- Assumpte: Re: [Simh] Speaking of cards Data: Mon, 27 May 2013 17:37:37 +0200 De: Jordi Guillaumes i Pons A: Tom Morris Al 27/05/13 16:58, En/na Tom Morris ha escrit: > "The DEC 026 code is a workable mapping of the IBM 026 FORTRAN > character set to ASCII. Unfortunately, it appears to have nothing in > common with other extensions of the same character set. Given the > frequency of typos in DEC's handbooks, it is possible that the problem > is with the handbook from which this material was derived." I recently added a new table (026DEC) to simh which corresponds with what does RSX11 and VMS expect when the reader is in 026 mode. The 029 mode was already correct, with a pair of mistakes I corrected. If you catch any error please open an issue at github so it can be corrected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jg at jordi.guillaumes.name Mon May 27 11:46:53 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 17:46:53 +0200 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A37443.8070002@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> Message-ID: <51A37FED.4010702@jordi.guillaumes.name> Al 27/05/13 16:57, En/na Timothe Litt ha escrit: > CDRIVE is trying to OPEN [sixbit/CDR000/] and fails, but doesn't > bother to say why. > > Too bad that it doesn't use FILOP. instead. > > Anyhow, OPEN will fail if the device doesn't exist, is in use, or > restricted. > > It clearly exists. CDRIVE runs under [1,2], so restricted shouldn't > be a problem. (opr> unrestrict cdr0 shouldn't be necessary, but might > tell us something). systat b should tell us if it's in use by some > other job. .r opr OPR>unrestrict cdr0 OPR> 17:41:59 --Device CDR0: unrestricted-- OPR>start reader 0 OPR> 17:42:10 Reader 0 -- Already Started -- OPR>shutdown reader 0 OPR> 17:42:17 Reader 0 -- Shutdown -- OPR>start reader 0 OPR> 17:42:23 Reader 0 -- Startup Scheduled -- OPR> 17:42:24 Reader 0 -- Not available right now -- OPR> 17:42:28 -- CDRIVE logging out -- All streams have been shutdown OPR>^Z .systat b No busy devices > How is it configured in simh - should be at 3,,777160, vector 230? bitxt1>> show cr CR address=3777160-3777167, vector=230, 1000 cards per minute translation=029 not attached, CD11, auto EOF unknown format > From Mark at infocomm.com Mon May 27 11:48:55 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 08:48:55 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A35D44.5090601@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> 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: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 > > > From litt at ieee.org Mon May 27 12:02:12 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:02:12 -0400 Subject: [Simh] Netcon In-Reply-To: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> Message-ID: <51A38384.2060504@ieee.org> Don't worry about the \ / inconsistency. It's just a delimiter - it needs to match for a given command. LOG OPERATOR + ENA (enable) is what gives permissions. That should be OK. Does spear report any errors from DECnet? Have your tried to use NCP to enable console logging? That should produce the DECnet events. I'd want to login, run NETCON manually with DDT to see what it's complaining about. But first, the other symptom. Only one end sending; no response to START. That's wierd, and nothing will work until it's fixed. If the line is on for both systems, they *both* should be sending STARTs, until one (or both) sends a STACK. Then the other sends ACK, and the link is up. So back to your code. On the end that's not sending anything: are the line and circuit ON? Are you seeing buffers queued? Is the data arriving and being delivered? What's different in its .INI file? How are you specifying the TCP (or UDP) socket destinations/port numbers? Are both ends opening successfully? A trace would help. Or maybe I should try running your code... This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:36, Robert Jarratt wrote: > The disks are cloned but I modified 4-1-config.cmd to change the node name > and number. That is all I did. So in one I have the line > NODE TOPS20 25 > And in the other I have > NODE TOPS21 26 > > I don't know much about how NETCON would get its permissions, it is being > started from SYSJOB.RUN, this is what I have in that file after following > the instructions in the manual I was following: > > RUN SYS:ORION > RUN SYS:QUASAR > RUN SYS:MOUNTR > RUN SYS:INFO > RUN SYS:MAILER > RUN SYS:MAPPER > RUN SYS:LPTSPL > RUN SYS:LPTSPL > RUN SYS:CDRIVE > RUN SYS:SPRINT > JOB 0 /LOG OPERATOR XX OPERATOR > ENA > ^ESET LOGIN PSEUDO > ^ESET LOGIN CONSOLE > ^ESET OPERATOR > PTYCON > GET SYSTEM:PTYCON.ATO > / > JOB 1 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:BATCON > / > JOB 2 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:FAL > / > JOB 3 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:NETCON > / > > Note that the manual used "\LOG" rather than "/LOG" but was contradictory on > this as in some places it was one and in others it was the other. > > I tried a loopback test, which failed as per the attached log file. > > One more data point. When I use UETP to verify the configuration I get these > errors in the log: > > $TYPE EXCEPT.LOG.2 > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.BWR.1 644032 P > Correct file: PS:DECNET.BWR.1 556602 P > > > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.DOC.1 350434 P > Correct file: PS:DECNET.DOC.1 614303 P > > They suggest that the docs are not right, but nothing else. > > Regards > > Rob > >> -----Original Message----- >> From: Timothe Litt [mailto:litt at ieee.org] >> Sent: 27 May 2013 14:35 >> To: Robert Jarratt >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] Netcon >> >>> owever, I still see one end repeatedly sending the first DDCMP message >>> (05 06 C0 00 00 01), but nothing else happens, no response going the >>> other way, no messages on the console etc. I notice that I do get this >>> message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL >>> INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % >>> NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still >>> don't have the right version of DECnet on this virtual machine? >>> Thanks! Rob >> Er, are you still running cloned systems? Make sure the node number and >> name are different between the two. >> >> As I wrote, I'd need to debug this, but it's possible that NETCON just >> isn't graceful about this. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:04:32 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:04:32 -0400 Subject: [Simh] Netcon In-Reply-To: <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <20130508000146.A1B69242BE@panix5.panix.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A360E9.3050107@ieee.org> <04f901ce5aef$e55883b0$b0098b10$@ntlworld.com> Message-ID: <51A38410.8070908@ieee.org> Oh, the loopback - CHKLBP.MAC isn't compiling. I can't tell if the log is jumbled, or if the code is really missing CRLFs. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:36, Robert Jarratt wrote: > The disks are cloned but I modified 4-1-config.cmd to change the node name > and number. That is all I did. So in one I have the line > NODE TOPS20 25 > And in the other I have > NODE TOPS21 26 > > I don't know much about how NETCON would get its permissions, it is being > started from SYSJOB.RUN, this is what I have in that file after following > the instructions in the manual I was following: > > RUN SYS:ORION > RUN SYS:QUASAR > RUN SYS:MOUNTR > RUN SYS:INFO > RUN SYS:MAILER > RUN SYS:MAPPER > RUN SYS:LPTSPL > RUN SYS:LPTSPL > RUN SYS:CDRIVE > RUN SYS:SPRINT > JOB 0 /LOG OPERATOR XX OPERATOR > ENA > ^ESET LOGIN PSEUDO > ^ESET LOGIN CONSOLE > ^ESET OPERATOR > PTYCON > GET SYSTEM:PTYCON.ATO > / > JOB 1 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:BATCON > / > JOB 2 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:FAL > / > JOB 3 /LOG OPERATOR XX OPERATOR > ENA > RUN SYS:NETCON > / > > Note that the manual used "\LOG" rather than "/LOG" but was contradictory on > this as in some places it was one and in others it was the other. > > I tried a loopback test, which failed as per the attached log file. > > One more data point. When I use UETP to verify the configuration I get these > errors in the log: > > $TYPE EXCEPT.LOG.2 > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.BWR.1 644032 P > Correct file: PS:DECNET.BWR.1 556602 P > > > ERROR VF2020 27-May-2013 10:32:24 0:00:00 > 0:00:00 > ? Mismatch occurred during verification: > Currently installed file: PS:DECNET.DOC.1 350434 P > Correct file: PS:DECNET.DOC.1 614303 P > > They suggest that the docs are not right, but nothing else. > > Regards > > Rob > >> -----Original Message----- >> From: Timothe Litt [mailto:litt at ieee.org] >> Sent: 27 May 2013 14:35 >> To: Robert Jarratt >> Cc: simh at trailing-edge.com >> Subject: Re: [Simh] Netcon >> >>> owever, I still see one end repeatedly sending the first DDCMP message >>> (05 06 C0 00 00 01), but nothing else happens, no response going the >>> other way, no messages on the console etc. I notice that I do get this >>> message on bootup though: SJ 3: $RUN SYS:NETCON SJ 2: ?ILLEGAL >>> INSTRUCTION 0 AT 236246 SJ 2: ?UNDEFINED OPERATION CODE SJ 3: SJ 3: % >>> NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY Could it be that I still >>> don't have the right version of DECnet on this virtual machine? >>> Thanks! Rob >> Er, are you still running cloned systems? Make sure the node number and >> name are different between the two. >> >> As I wrote, I'd need to debug this, but it's possible that NETCON just >> isn't graceful about this. >> >> >> This communication may not represent my employer's views, >> if any, on the matters discussed. >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:09:36 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:09:36 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A37FED.4010702@jordi.guillaumes.name> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <030e01ce546e$67754f00$365fed00$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> Message-ID: <51A38540.9050903@ieee.org> simh says 'not attached' You need to attach it at the simh prompt to a file of card images. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:46, Jordi Guillaumes i Pons wrote: > Al 27/05/13 16:57, En/na Timothe Litt ha escrit: >> CDRIVE is trying to OPEN [sixbit/CDR000/] and fails, but doesn't >> bother to say why. >> >> Too bad that it doesn't use FILOP. instead. >> >> Anyhow, OPEN will fail if the device doesn't exist, is in use, or >> restricted. >> >> It clearly exists. CDRIVE runs under [1,2], so restricted shouldn't >> be a problem. (opr> unrestrict cdr0 shouldn't be necessary, but >> might tell us something). systat b should tell us if it's in use by >> some other job. > > > .r opr > > OPR>unrestrict cdr0 > OPR> > 17:41:59 --Device CDR0: unrestricted-- > OPR>start reader 0 > OPR> > 17:42:10 Reader 0 -- Already Started -- > OPR>shutdown reader 0 > OPR> > 17:42:17 Reader 0 -- Shutdown -- > OPR>start reader 0 > OPR> > 17:42:23 Reader 0 -- Startup Scheduled -- > OPR> > 17:42:24 Reader 0 -- Not available right now -- > OPR> > 17:42:28 -- CDRIVE logging out -- > All streams have been shutdown > OPR>^Z > .systat b > > No busy devices > >> How is it configured in simh - should be at 3,,777160, vector 230? > bitxt1>> show cr > CR address=3777160-3777167, vector=230, 1000 cards per minute > translation=029 > not attached, CD11, auto EOF > unknown format > > >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 12:27:43 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 12:27:43 -0400 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> Message-ID: <51A3897F.7020203@ieee.org> Hopefully, when the KDP is working Rob will merge (and if necessary debug) my changes & commit them to fix both problems. Ideally adding the page optimization, but beggars can't be choosers. If he doesn't I'll try to get to that later (if I have commit access to simh on github). I suppose I should see about building a current version, as I seem to be in the middle of debugging several things by Braille... (Or is this simply a memory test for me :-) This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > 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. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 13:34:19 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 10:34:19 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <51A3897F.7020203@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> Hi Tim, On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > Hopefully, when the KDP is working Rob will merge (and if necessary > debug) my changes & commit them to fix both problems. Ideally adding > the page optimization, but beggars can't be choosers. If he doesn't > I'll try to get to that later (if I have commit access to simh on github). You don't need commit access to the core repository on Github to get your changes submitted and accepted. The github paradigm is: 1) you create a personal account on github. 2) you 'clone' the github simh/simh repository to your personal github space. 3) you clone either of these to your working environment and do your work and check-in locally as desired/needed. 4) you configure your local repo to have your personal github repo as the primary push repo and the siimh/simh one as another remote repository. Steps 2 and 3 can be in any order. When you are ready to submit your changes, you: 1) you pull from the simh/simh and merge to the latest codebase 2) you push your local working repo to your personal github repo 3) Using the github web UI you create a pull request for the github simh/simh repo. This pull request will create an issue which will track the details of what will happen. I'll review the changes and either accept them as is and simply complete the merge or I'll respond with some comments and/or suggestions and you can make revisions until we're both happy and the merge will be completed. Once the merge completes, each of your commits (with your name) will be part of the repository/history. If you don't want to climb the learning curve of using git, I'll be glad to take changes which I'd prefer be the complete files of any files you've changed along with a description (as verbose as you may want) of the point of the changes and I'll review and commit these using the description as the commit message. I'll credit you in the commit comments, but the commit will have my name on it. If you go down this path, you can send all of the files as separate attachments or preferably bundle them in a zip file and send it via email (there is no problem is you include extra files which you didn't actually change since git will only notice the changed content anyway). Without regard to climbing the git learning curve, If you create a github account and let me know you've done it, I'll add you as a contributor to the project and assign issues to you where appropriate. If you create a github account now, and create an issue at https://github.com/simh/simh/issues describing the problems with Map_WriteW, I'll assign that issue to you and when you ultimately submit fixes, the pull request you create can be the fix to the issue... > I suppose I should see about building a current version, as I seem to be > in the middle of debugging several things by Braille... (Or is this > simply a memory test for me :-) Without jumping into git, you can always pickup the latest code at https://github.com/simh/simh/archive/master.zip I look forward to anything you've got to offer. Thanks. - Mark > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > 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. > > > From aek at bitsavers.org Mon May 27 14:47:44 2013 From: aek at bitsavers.org (Al Kossow) Date: Mon, 27 May 2013 11:47:44 -0700 Subject: [Simh] Speaking of cards In-Reply-To: <51A36F63.9050609@bitsavers.org> References: <51A36A38.3060106@ieee.org> <51A36F63.9050609@bitsavers.org> Message-ID: <51A3AA50.9070601@bitsavers.org> On 5/27/13 7:36 AM, Al Kossow wrote: > On 5/27/13 7:14 AM, Timothe Litt wrote: > >> I have some blank punch cards, I should scan one as it only comes with some customized images. >> > > I can make a high resolution scan of a buff 5081 if it's needed. > I just uploaded a scan of four different 5081 style cards to http://bitsavers.org/pdf/ibm/punchedCard/Card_Scans it will take an hour or two for it to get out to the mirrors From litt at ieee.org Mon May 27 15:12:19 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 15:12:19 -0400 Subject: [Simh] Speaking of cards In-Reply-To: <51A3AA50.9070601@bitsavers.org> References: <51A36A38.3060106@ieee.org> <51A36F63.9050609@bitsavers.org> <51A3AA50.9070601@bitsavers.org> Message-ID: <51A3B013.3020004@ieee.org> Al, Thanks. I'll look for them. I just figured out how to scan and convert so the size comes out right, which was non trivial. I scanned at 100dpi (close to screen resolution), used imagemagick's convert -colors 256 in.png out.xpm. I couldn't get resize or resample or any other permutations to produce the right size from higher resolution scans. Anyhow, I've added one pink and one Harvard card. Do you want the scans for your collection? In one case I had to unpunch a few holes...sorta like the scotch tape I used to use with chad and the duplicator when I was desperate. But easier :-) I'll add yours and will see if the originator wants to take the changes; else I guess it will go to tools of simh. I also found some detailed reference material on the 029; there's a lot to do for a reasonable emulation. I'd forgotten that they did check digits of fields with relay logic! I'll ping the author (said he wanted feedback/suggestions, but that was 10 years ago!). If he's no longer interested, I may play some, or just post the task list to the list and see if someone else bites. In any case, I'm pretty sure I don't have the skills to wrap an X-windows image of an arbitrary drum card around a cylinder and rotate it while the machine works. Hopefully I won't spend the night sneezing from all the dust this has kicked up. This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 14:47, Al Kossow wrote: > On 5/27/13 7:36 AM, Al Kossow wrote: >> On 5/27/13 7:14 AM, Timothe Litt wrote: >> >>> I have some blank punch cards, I should scan one as it only comes >>> with some customized images. >>> >> >> I can make a high resolution scan of a buff 5081 if it's needed. >> > > I just uploaded a scan of four different 5081 style cards to > http://bitsavers.org/pdf/ibm/punchedCard/Card_Scans > > it will take an hour or two for it to get out to the mirrors > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From litt at ieee.org Mon May 27 15:24:28 2013 From: litt at ieee.org (Timothe Litt) Date: Mon, 27 May 2013 15:24:28 -0400 Subject: [Simh] card reader and running commands In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> Message-ID: <51A3B2EC.70305@ieee.org> RE: the 'what commands should we be able to do without stopping the simulator' discussion: Based on this, "set cr reset" is one of them that we didn't think of before. (Or at least, I didn't.) This communication may not represent my employer's views, if any, on the matters discussed. On 27-May-13 15:00, Jordi Guillaumes i Pons wrote: > El 27/05/2013, a les 18:09, Timothe Litt va escriure: > >> simh says 'not attached' You need to attach it at the simh prompt to a file of card images. > Oh, yes, I'm aware of that. I attached CR to a file with this content: > > $JOB OPERATOR > $PASSWORD ****** > ! Obtencio llistat de directoris > ! > INICI:: > . DEL DIR.LST > . DEL DIRDIZ.DAT > . DEL DIRSIZ.LST > ! > P010:: > . CHKPNT P010 > . R DIRECT > * DIR.LST=[*,*,*,*,*]*.* > * ^Z > P020:: > . CHKPNT P020 > . RUN DIRSZ1 > P030:: > . CHKPNT P030 > . RUN DIRSZ2 > . TYPE DIRSIZ.LST > $EOJ > > Never mind the comments and the programs, those WORK when I submit this file using the SUBMIT command. Then I do a SET CR RESET (as directed by the simh docs... it works for VMS and RSX :)) and... nothing happens. > > The card reader is indeed seen by the operating system: > > CONFIG>show hardWARE-CONFIGURATION (of system) /unit-record > CONFIG> > 20:56:52 CONFIG -- SHOW HARDWARE-CONFIGURATION -- > > > Unit Record Device Configuration > > Card reader configuration: > Device CPU > ------ --- > CDR0 0 > > Line printer configuration: > Device CPU Type Status > ------ --- ----- ------ > LPT0 0 LP20 Online > > It looks like everything is OK, but it does not work. That is the reason why I think there is some bug in the CD11 implementation in the simh side. > > > Jordi Guillaumes i Pons > jg at jordi.guillaumes.name > HECnet: BITXOV::JGUILLAUMES > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Mark at infocomm.com Mon May 27 15:36:18 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 12:36:18 -0700 Subject: [Simh] card reader and running commands In-Reply-To: <51A3B2EC.70305@ieee.org> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2EC.70305@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 12:24 PM, Timothe Litt wrote: > RE: the 'what commands should we be able to do without stopping the > simulator' discussion: > > Based on this, "set cr reset" is one of them that we didn't think of > before. (Or at least, I didn't.) This will work just fine with the remote console support currently available in the current simh code base at github. The Remote Console Facility allows a TELNET Connection to a user designated port so that some out of band commands can be entered to manipulate and/or adjust a running simulator. The commands which enable and control this capability are SET REMOTE TELNET=port, SET REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. The remote console facility has two modes of operation: 1) single command mode. and 2) multiple command mode. In single command mode you enter one command at a time and aren't concerned about what the simulated system is doing while you enter that command. The command is executed once you've hit return. In multiple command mode you initiate your activities by entering the WRU character (usually ^E). This will suspend the current simulator execution. You then enter commands as needed and when you are done you enter a CONTINUE command. While entering Multiple Command commands, if you fail to enter a complete command before the timeout (specified by "SET REMOTE TIMEOUT=seconds"), a CONTINUE command is automatically processed and simulation proceeds. A subset of normal simh commands are available for use in remote console sessions. The Single Command Mode commands are: ATTACH, DETACH, PWD, SHOW, DIR, LS, ECHO, HELP The Multiple Command Mode commands are: EXAMINE, IEXAMINE, DEPOSIT, EVALUATE, ATTACH, DETACH, ASSIGN, DEASSIGN, STEP, CONTINUE, PWD, SAVE, SET, SHOW, DIR, LS, ECHO, HELP > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 27-May-13 15:00, Jordi Guillaumes i Pons wrote: > > El 27/05/2013, a les 18:09, Timothe Litt va escriure: > > > >> simh says 'not attached' You need to attach it at the simh prompt to a file > of card images. > > Oh, yes, I'm aware of that. I attached CR to a file with this content: > > > > $JOB OPERATOR > > $PASSWORD ****** > > ! Obtencio llistat de directoris > > ! > > INICI:: > > . DEL DIR.LST > > . DEL DIRDIZ.DAT > > . DEL DIRSIZ.LST > > ! > > P010:: > > . CHKPNT P010 > > . R DIRECT > > * DIR.LST=[*,*,*,*,*]*.* > > * ^Z > > P020:: > > . CHKPNT P020 > > . RUN DIRSZ1 > > P030:: > > . CHKPNT P030 > > . RUN DIRSZ2 > > . TYPE DIRSIZ.LST > > $EOJ > > > > Never mind the comments and the programs, those WORK when I submit > this file using the SUBMIT command. Then I do a SET CR RESET (as directed by > the simh docs... it works for VMS and RSX :)) and... nothing happens. > > > > The card reader is indeed seen by the operating system: > > > > CONFIG>show hardWARE-CONFIGURATION (of system) /unit-record > > CONFIG> > > 20:56:52 CONFIG -- SHOW HARDWARE-CONFIGURATION -- > > > > > > Unit Record Device Configuration > > > > Card reader configuration: > > Device CPU > > ------ --- > > CDR0 0 > > > > Line printer configuration: > > Device CPU Type Status > > ------ --- ----- ------ > > LPT0 0 LP20 Online > > > > It looks like everything is OK, but it does not work. That is the reason why I > think there is some bug in the CD11 implementation in the simh side. > > > > > > Jordi Guillaumes i Pons > > jg at jordi.guillaumes.name > > HECnet: BITXOV::JGUILLAUMES > > > > > > > > > From jg at jordi.guillaumes.name Mon May 27 16:11:53 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Mon, 27 May 2013 22:11:53 +0200 Subject: [Simh] card reader and running commands In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm va escriure: > The Remote Console Facility allows a TELNET Connection to a user designated port so that some out of band commands can be entered to manipulate and/or adjust a running simulator. The commands which enable and control this capability are SET REMOTE TELNET=port, SET REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. Hi Mark, The remote console addition is really useful! (It would justify upgrading simh to 4.0 by itself, in my opinion). I, however, have a suggestion: could you add a command to disconnect the telnet session? Right now the only way is to break into TELNET command mode and CLOSE the connection there... Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From Mark at infocomm.com Mon May 27 16:25:13 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 13:25:13 -0700 Subject: [Simh] card reader and running commands In-Reply-To: References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DB@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:12 PM, Jordi wrote: > El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm > va escriure: > > > The Remote Console Facility allows a TELNET Connection to a user > designated port so that some out of band commands can be entered to > manipulate and/or adjust a running simulator. The commands which enable > and control this capability are SET REMOTE TELNET=port, SET REMOTE > CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW REMOTE. > > Hi Mark, > > The remote console addition is really useful! (It would justify upgrading simh > to 4.0 by itself, in my opinion). I, however, have a suggestion: could you add a > command to disconnect the telnet session? Right now the only way is to > break into TELNET command mode and CLOSE the connection there... Hmmm... You have to do the same thing to disconnect from any console session.... This seems easy enough... From robert.jarratt at ntlworld.com Mon May 27 16:42:41 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 21:42:41 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> Message-ID: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Mark, It is time for me to start learning about git. The bit I am struggling to understand right now is now to clone your repository to my personal space on github, can I do this from the web site? Regards Rob > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 18:34 > To: Timothe Litt; Mark Pizzolato - Info Comm > Cc: Robert Jarratt; simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > Hi Tim, > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > Hopefully, when the KDP is working Rob will merge (and if necessary > > debug) my changes & commit them to fix both problems. Ideally adding > > the page optimization, but beggars can't be choosers. If he doesn't > > I'll try to get to that later (if I have commit access to simh on github). > > You don't need commit access to the core repository on Github to get your > changes submitted and accepted. The github paradigm is: > 1) you create a personal account on github. > 2) you 'clone' the github simh/simh repository to your personal github > space. > 3) you clone either of these to your working environment and do your work > and check-in locally as desired/needed. > 4) you configure your local repo to have your personal github repo as the > primary push repo and the siimh/simh one as another remote repository. > Steps 2 and 3 can be in any order. > When you are ready to submit your changes, you: > 1) you pull from the simh/simh and merge to the latest codebase > 2) you push your local working repo to your personal github repo > 3) Using the github web UI you create a pull request for the github > simh/simh repo. This pull request will create an issue which will track the > details of what will happen. > I'll review the changes and either accept them as is and simply complete the > merge or I'll respond with some comments and/or suggestions and you can > make revisions until we're both happy and the merge will be completed. > Once the merge completes, each of your commits (with your name) will be > part of the repository/history. > > If you don't want to climb the learning curve of using git, I'll be glad to take > changes which I'd prefer be the complete files of any files you've changed > along with a description (as verbose as you may want) of the point of the > changes and I'll review and commit these using the description as the commit > message. I'll credit you in the commit comments, but the commit will have > my name on it. If you go down this path, you can send all of the files as > separate attachments or preferably bundle them in a zip file and send it via > email (there is no problem is you include extra files which you didn't actually > change since git will only notice the changed content anyway). > > Without regard to climbing the git learning curve, If you create a github > account and let me know you've done it, I'll add you as a contributor to the > project and assign issues to you where appropriate. If you create a github > account now, and create an issue at https://github.com/simh/simh/issues > describing the problems with Map_WriteW, I'll assign that issue to you and > when you ultimately submit fixes, the pull request you create can be the fix > to the issue... > > > I suppose I should see about building a current version, as I seem to > > be in the middle of debugging several things by Braille... (Or is > > this simply a memory test for me :-) > > Without jumping into git, you can always pickup the latest code at > https://github.com/simh/simh/archive/master.zip > > I look forward to anything you've got to offer. > > Thanks. > > - Mark > > > This communication may not represent my employer's views, if any, on > > the matters discussed. > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > 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. > > > > > From toby at telegraphics.com.au Mon May 27 16:51:18 2013 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 27 May 2013 16:51:18 -0400 Subject: [Simh] Starting with git/github - Re: TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Message-ID: <51A3C746.3000202@telegraphics.com.au> On 27/05/13 4:42 PM, Robert Jarratt wrote: > Mark, > > It is time for me to start learning about git. The bit I am struggling to > understand right now is now to clone your repository to my personal space on > github, can I do this from the web site? Yes, the operation is called "Fork". "Cloning" is when you create a local copy (e.g. with git clone on CLI). --Toby > > Regards > > Rob > From Mark at infocomm.com Mon May 27 16:53:44 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 13:53:44 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > Mark, > > It is time for me to start learning about git. The bit I am struggling to > understand right now is now to clone your repository to my personal space > on github, can I do this from the web site? Yes. Cloning is both a concept and a raw git command you can use on the command line at a shell prompt. The command: $ git clone git://github.com/simh/simh.git This will create a local repository copy of the simh github repository. I use "Git Extensions" on my windows desktop as a git GUI. The Git Extensions interface has a clone GUI as well. It also provides a "bash shell" which you can enter direct git commands if/when you need to do this. Meanwhile, the github site's interface at https://github.com/simh/simh has a "Fork" button in the upper right hand corner. This fork operation creates a clone of the repository in your personal github account. Please ask as many questions as you want. The more you know the easier it will be for you to climb this hill.. Good Luck, - Mark > Regards > > Rob > > > -----Original Message----- > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > Sent: 27 May 2013 18:34 > > To: Timothe Litt; Mark Pizzolato - Info Comm > > Cc: Robert Jarratt; simh at trailing-edge.com > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > Hi Tim, > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > Hopefully, when the KDP is working Rob will merge (and if necessary > > > debug) my changes & commit them to fix both problems. Ideally > > > adding the page optimization, but beggars can't be choosers. If he > > > doesn't I'll try to get to that later (if I have commit access to > > > simh on > github). > > > > You don't need commit access to the core repository on Github to get > > your changes submitted and accepted. The github paradigm is: > > 1) you create a personal account on github. > > 2) you 'clone' the github simh/simh repository to your personal > > github space. > > 3) you clone either of these to your working environment and do your > work > > and check-in locally as desired/needed. > > 4) you configure your local repo to have your personal github repo > > as > the > > primary push repo and the siimh/simh one as another remote repository. > > Steps 2 and 3 can be in any order. > > When you are ready to submit your changes, you: > > 1) you pull from the simh/simh and merge to the latest codebase > > 2) you push your local working repo to your personal github repo > > 3) Using the github web UI you create a pull request for the github > > simh/simh repo. This pull request will create an issue which will > > track > the > > details of what will happen. > > I'll review the changes and either accept them as is and simply > > complete > the > > merge or I'll respond with some comments and/or suggestions and you > > can make revisions until we're both happy and the merge will be > completed. > > Once the merge completes, each of your commits (with your name) will > > be part of the repository/history. > > > > If you don't want to climb the learning curve of using git, I'll be > > glad > to take > > changes which I'd prefer be the complete files of any files you've > > changed along with a description (as verbose as you may want) of the > > point of the changes and I'll review and commit these using the > > description as the > commit > > message. I'll credit you in the commit comments, but the commit will > > have my name on it. If you go down this path, you can send all of the > > files as separate attachments or preferably bundle them in a zip file > > and send it > via > > email (there is no problem is you include extra files which you didn't > actually > > change since git will only notice the changed content anyway). > > > > Without regard to climbing the git learning curve, If you create a > > github account and let me know you've done it, I'll add you as a > > contributor to > the > > project and assign issues to you where appropriate. If you create a > github > > account now, and create an issue at > > https://github.com/simh/simh/issues > > describing the problems with Map_WriteW, I'll assign that issue to > > you > and > > when you ultimately submit fixes, the pull request you create can be > > the > fix > > to the issue... > > > > > I suppose I should see about building a current version, as I seem > > > to be in the middle of debugging several things by Braille... (Or > > > is this simply a memory test for me :-) > > > > Without jumping into git, you can always pickup the latest code at > > https://github.com/simh/simh/archive/master.zip > > > > I look forward to anything you've got to offer. > > > > Thanks. > > > > - Mark > > > > > This communication may not represent my employer's views, if any, on > > > the matters discussed. > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > 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. > > > > > > > > > From robert.jarratt at ntlworld.com Mon May 27 17:41:56 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 22:41:56 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> Message-ID: <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> Ah, I wondered if that is what you meant. Perhaps it would be a good idea to post something on GitHub (if there is a suitable place), to give newbies guidance on how to get set up. Any questions people ask could go in a FAQ, then you don't have to keep repeating yourself... :-) How are we going to manage Visual Studio Projects though? As you know, I use Visual Studio 2012 Express edition, so when I add files to the project, the project file will be in 2012 format, but the master is in an older format (2008 iirc). Won't we get into versioning conflicts? Regards Rob > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 21:54 > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > Mark, > > > > It is time for me to start learning about git. The bit I am struggling > > to understand right now is now to clone your repository to my personal > > space on github, can I do this from the web site? > > Yes. Cloning is both a concept and a raw git command you can use on the > command line at a shell prompt. The command: > > $ git clone git://github.com/simh/simh.git > > This will create a local repository copy of the simh github repository. I use > "Git Extensions" on my windows desktop as a git GUI. The Git Extensions > interface has a clone GUI as well. It also provides a "bash shell" which you > can enter direct git commands if/when you need to do this. > > Meanwhile, the github site's interface at https://github.com/simh/simh has a > "Fork" button in the upper right hand corner. This fork operation creates a > clone of the repository in your personal github account. > > Please ask as many questions as you want. The more you know the easier it > will be for you to climb this hill.. > > Good Luck, > > - Mark > > > Regards > > > > Rob > > > > > -----Original Message----- > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > Sent: 27 May 2013 18:34 > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > Hi Tim, > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > necessary > > > > debug) my changes & commit them to fix both problems. Ideally > > > > adding the page optimization, but beggars can't be choosers. If > > > > he doesn't I'll try to get to that later (if I have commit access > > > > to simh on > > github). > > > > > > You don't need commit access to the core repository on Github to get > > > your changes submitted and accepted. The github paradigm is: > > > 1) you create a personal account on github. > > > 2) you 'clone' the github simh/simh repository to your personal > > > github space. > > > 3) you clone either of these to your working environment and do > > > your > > work > > > and check-in locally as desired/needed. > > > 4) you configure your local repo to have your personal github repo > > > as > > the > > > primary push repo and the siimh/simh one as another remote repository. > > > Steps 2 and 3 can be in any order. > > > When you are ready to submit your changes, you: > > > 1) you pull from the simh/simh and merge to the latest codebase > > > 2) you push your local working repo to your personal github repo > > > 3) Using the github web UI you create a pull request for the > > > github simh/simh repo. This pull request will create an issue which > > > will track > > the > > > details of what will happen. > > > I'll review the changes and either accept them as is and simply > > > complete > > the > > > merge or I'll respond with some comments and/or suggestions and you > > > can make revisions until we're both happy and the merge will be > > completed. > > > Once the merge completes, each of your commits (with your name) will > > > be part of the repository/history. > > > > > > If you don't want to climb the learning curve of using git, I'll be > > > glad > > to take > > > changes which I'd prefer be the complete files of any files you've > > > changed along with a description (as verbose as you may want) of the > > > point of the changes and I'll review and commit these using the > > > description as the > > commit > > > message. I'll credit you in the commit comments, but the commit > > > will have my name on it. If you go down this path, you can send all > > > of the files as separate attachments or preferably bundle them in a > > > zip file and send it > > via > > > email (there is no problem is you include extra files which you > > > didn't > > actually > > > change since git will only notice the changed content anyway). > > > > > > Without regard to climbing the git learning curve, If you create a > > > github account and let me know you've done it, I'll add you as a > > > contributor to > > the > > > project and assign issues to you where appropriate. If you create a > > github > > > account now, and create an issue at > > > https://github.com/simh/simh/issues > > > describing the problems with Map_WriteW, I'll assign that issue to > > > you > > and > > > when you ultimately submit fixes, the pull request you create can be > > > the > > fix > > > to the issue... > > > > > > > I suppose I should see about building a current version, as I seem > > > > to be in the middle of debugging several things by Braille... (Or > > > > is this simply a memory test for me :-) > > > > > > Without jumping into git, you can always pickup the latest code at > > > https://github.com/simh/simh/archive/master.zip > > > > > > I look forward to anything you've got to offer. > > > > > > Thanks. > > > > > > - Mark > > > > > > > This communication may not represent my employer's views, if any, > > > > on the matters discussed. > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > 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. > > > > > > > > > > > > > From Mark at infocomm.com Mon May 27 18:03:32 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Mon, 27 May 2013 15:03:32 -0700 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 2:42 PM, Robert Jarratt wrote: > Ah, I wondered if that is what you meant. Perhaps it would be a good idea to > post something on GitHub (if there is a suitable place), to give newbies > guidance on how to get set up. Any questions people ask could go in a FAQ, > then you don't have to keep repeating yourself... :-) Good point. Let me think about how/where to keep this info. > How are we going to manage Visual Studio Projects though? As you know, I > use Visual Studio 2012 Express edition, so when I add files to the project, the > project file will be in 2012 format, but the master is in an older format > (2008 iirc). Won't we get into versioning conflicts? Good question. Project definition files change very rarely. I would suggest that you DON'T check-in your changed projects. By default, the current repository is setup to not 'notice' new files (i.e. your .vcxproj files) in the Visual Studio Projects directory, so you really won't have to think much about this. When visual studio 'auto-converts' the default (Visual Studio 2008) projects to ones appropriate for your Visual Studio version, it will change the simh.sln file with pointers to the new project files. Git will notice this change since the simh.sln file is already managed under source control. When you do a commit/check-in, do not check-in the simh.sln file. As part of me pulling in your new code I'll find that it won't build cleanly in my test environment and I'll fix the base project files and ALSO go and update the makefile and descrip.mms to reflect the required corresponding changes. > > -----Original Message----- > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > Sent: 27 May 2013 21:54 > > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > > Cc: simh at trailing-edge.com > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > > Mark, > > > > > > It is time for me to start learning about git. The bit I am > > > struggling to understand right now is now to clone your repository > > > to my personal space on github, can I do this from the web site? > > > > Yes. Cloning is both a concept and a raw git command you can use on > > the command line at a shell prompt. The command: > > > > $ git clone git://github.com/simh/simh.git > > > > This will create a local repository copy of the simh github > > repository. I > use > > "Git Extensions" on my windows desktop as a git GUI. The Git > > Extensions interface has a clone GUI as well. It also provides a > > "bash shell" which > you > > can enter direct git commands if/when you need to do this. > > > > Meanwhile, the github site's interface at https://github.com/simh/simh > > has > a > > "Fork" button in the upper right hand corner. This fork operation > > creates > a > > clone of the repository in your personal github account. > > > > Please ask as many questions as you want. The more you know the > > easier it will be for you to climb this hill.. > > > > Good Luck, > > > > - Mark > > > > > Regards > > > > > > Rob > > > > > > > -----Original Message----- > > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > > Sent: 27 May 2013 18:34 > > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > > > Hi Tim, > > > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > > necessary > > > > > debug) my changes & commit them to fix both problems. Ideally > > > > > adding the page optimization, but beggars can't be choosers. If > > > > > he doesn't I'll try to get to that later (if I have commit > > > > > access to simh on > > > github). > > > > > > > > You don't need commit access to the core repository on Github to > > > > get your changes submitted and accepted. The github paradigm is: > > > > 1) you create a personal account on github. > > > > 2) you 'clone' the github simh/simh repository to your personal > > > > github space. > > > > 3) you clone either of these to your working environment and do > > > > your > > > work > > > > and check-in locally as desired/needed. > > > > 4) you configure your local repo to have your personal github > > > > repo as > > > the > > > > primary push repo and the siimh/simh one as another remote > repository. > > > > Steps 2 and 3 can be in any order. > > > > When you are ready to submit your changes, you: > > > > 1) you pull from the simh/simh and merge to the latest codebase > > > > 2) you push your local working repo to your personal github repo > > > > 3) Using the github web UI you create a pull request for the > > > > github simh/simh repo. This pull request will create an issue > > > > which will track > > > the > > > > details of what will happen. > > > > I'll review the changes and either accept them as is and simply > > > > complete > > > the > > > > merge or I'll respond with some comments and/or suggestions and > > > > you can make revisions until we're both happy and the merge will > > > > be > > > completed. > > > > Once the merge completes, each of your commits (with your name) > > > > will be part of the repository/history. > > > > > > > > If you don't want to climb the learning curve of using git, I'll > > > > be glad > > > to take > > > > changes which I'd prefer be the complete files of any files you've > > > > changed along with a description (as verbose as you may want) of > > > > the point of the changes and I'll review and commit these using > > > > the description as the > > > commit > > > > message. I'll credit you in the commit comments, but the commit > > > > will have my name on it. If you go down this path, you can send > > > > all of the files as separate attachments or preferably bundle them > > > > in a zip file and send it > > > via > > > > email (there is no problem is you include extra files which you > > > > didn't > > > actually > > > > change since git will only notice the changed content anyway). > > > > > > > > Without regard to climbing the git learning curve, If you create a > > > > github account and let me know you've done it, I'll add you as a > > > > contributor to > > > the > > > > project and assign issues to you where appropriate. If you create > > > > a > > > github > > > > account now, and create an issue at > > > > https://github.com/simh/simh/issues > > > > describing the problems with Map_WriteW, I'll assign that issue > > > > to you > > > and > > > > when you ultimately submit fixes, the pull request you create can > > > > be the > > > fix > > > > to the issue... > > > > > > > > > I suppose I should see about building a current version, as I > > > > > seem to be in the middle of debugging several things by > > > > > Braille... (Or is this simply a memory test for me :-) > > > > > > > > Without jumping into git, you can always pickup the latest code at > > > > https://github.com/simh/simh/archive/master.zip > > > > > > > > I look forward to anything you've got to offer. > > > > > > > > Thanks. > > > > > > > > - Mark > > > > > > > > > This communication may not represent my employer's views, if > > > > > any, on the matters discussed. > > > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > > 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. > > > > > > > > > > > > > > > > > > > From robert.jarratt at ntlworld.com Mon May 27 18:23:25 2013 From: robert.jarratt at ntlworld.com (Robert Jarratt) Date: Mon, 27 May 2013 23:23:25 +0100 Subject: [Simh] TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198A8C6.7030706@ieee.org> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> Message-ID: <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> Would I be able to check the solution and project files into my own repo and somehow avoid sending those commits to you, assuming I can keep them separate from the other changes? > -----Original Message----- > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > Sent: 27 May 2013 23:04 > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > Cc: simh at trailing-edge.com > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > On Monday, May 27, 2013 at 2:42 PM, Robert Jarratt wrote: > > Ah, I wondered if that is what you meant. Perhaps it would be a good > > idea to post something on GitHub (if there is a suitable place), to > > give newbies guidance on how to get set up. Any questions people ask > > could go in a FAQ, then you don't have to keep repeating yourself... > > :-) > > Good point. Let me think about how/where to keep this info. > > > How are we going to manage Visual Studio Projects though? As you know, > > I use Visual Studio 2012 Express edition, so when I add files to the > > project, the project file will be in 2012 format, but the master is in > > an older format > > (2008 iirc). Won't we get into versioning conflicts? > > Good question. Project definition files change very rarely. I would suggest > that you DON'T check-in your changed projects. By default, the current > repository is setup to not 'notice' new files (i.e. your .vcxproj files) in the > Visual Studio Projects directory, so you really won't have to think much about > this. When visual studio 'auto-converts' the default (Visual Studio 2008) > projects to ones appropriate for your Visual Studio version, it will change the > simh.sln file with pointers to the new project files. Git will notice this change > since the simh.sln file is already managed under source control. When you > do a commit/check-in, do not check-in the simh.sln file. As part of me pulling > in your new code I'll find that it won't build cleanly in my test environment > and I'll fix the base project files and ALSO go and update the makefile and > descrip.mms to reflect the required corresponding changes. > > > > -----Original Message----- > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > Sent: 27 May 2013 21:54 > > > To: Robert Jarratt; Mark Pizzolato - Info Comm; 'Timothe Litt' > > > Cc: simh at trailing-edge.com > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > On Monday, May 27, 2013 at 1:43 PM, Rob Jarratt wrote: > > > > Mark, > > > > > > > > It is time for me to start learning about git. The bit I am > > > > struggling to understand right now is now to clone your repository > > > > to my personal space on github, can I do this from the web site? > > > > > > Yes. Cloning is both a concept and a raw git command you can use on > > > the command line at a shell prompt. The command: > > > > > > $ git clone git://github.com/simh/simh.git > > > > > > This will create a local repository copy of the simh github > > > repository. I > > use > > > "Git Extensions" on my windows desktop as a git GUI. The Git > > > Extensions interface has a clone GUI as well. It also provides a > > > "bash shell" which > > you > > > can enter direct git commands if/when you need to do this. > > > > > > Meanwhile, the github site's interface at > > > https://github.com/simh/simh has > > a > > > "Fork" button in the upper right hand corner. This fork operation > > > creates > > a > > > clone of the repository in your personal github account. > > > > > > Please ask as many questions as you want. The more you know the > > > easier it will be for you to climb this hill.. > > > > > > Good Luck, > > > > > > - Mark > > > > > > > Regards > > > > > > > > Rob > > > > > > > > > -----Original Message----- > > > > > From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com] > > > > > Sent: 27 May 2013 18:34 > > > > > To: Timothe Litt; Mark Pizzolato - Info Comm > > > > > Cc: Robert Jarratt; simh at trailing-edge.com > > > > > Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code? > > > > > > > > > > Hi Tim, > > > > > > > > > > On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote: > > > > > > Hopefully, when the KDP is working Rob will merge (and if > > > > > > necessary > > > > > > debug) my changes & commit them to fix both problems. Ideally > > > > > > adding the page optimization, but beggars can't be choosers. > > > > > > If he doesn't I'll try to get to that later (if I have commit > > > > > > access to simh on > > > > github). > > > > > > > > > > You don't need commit access to the core repository on Github to > > > > > get your changes submitted and accepted. The github paradigm is: > > > > > 1) you create a personal account on github. > > > > > 2) you 'clone' the github simh/simh repository to your > > > > > personal github space. > > > > > 3) you clone either of these to your working environment and > > > > > do your > > > > work > > > > > and check-in locally as desired/needed. > > > > > 4) you configure your local repo to have your personal github > > > > > repo as > > > > the > > > > > primary push repo and the siimh/simh one as another remote > > repository. > > > > > Steps 2 and 3 can be in any order. > > > > > When you are ready to submit your changes, you: > > > > > 1) you pull from the simh/simh and merge to the latest codebase > > > > > 2) you push your local working repo to your personal github repo > > > > > 3) Using the github web UI you create a pull request for the > > > > > github simh/simh repo. This pull request will create an issue > > > > > which will track > > > > the > > > > > details of what will happen. > > > > > I'll review the changes and either accept them as is and simply > > > > > complete > > > > the > > > > > merge or I'll respond with some comments and/or suggestions and > > > > > you can make revisions until we're both happy and the merge will > > > > > be > > > > completed. > > > > > Once the merge completes, each of your commits (with your name) > > > > > will be part of the repository/history. > > > > > > > > > > If you don't want to climb the learning curve of using git, I'll > > > > > be glad > > > > to take > > > > > changes which I'd prefer be the complete files of any files > > > > > you've changed along with a description (as verbose as you may > > > > > want) of the point of the changes and I'll review and commit > > > > > these using the description as the > > > > commit > > > > > message. I'll credit you in the commit comments, but the commit > > > > > will have my name on it. If you go down this path, you can send > > > > > all of the files as separate attachments or preferably bundle > > > > > them in a zip file and send it > > > > via > > > > > email (there is no problem is you include extra files which you > > > > > didn't > > > > actually > > > > > change since git will only notice the changed content anyway). > > > > > > > > > > Without regard to climbing the git learning curve, If you create > > > > > a github account and let me know you've done it, I'll add you as > > > > > a contributor to > > > > the > > > > > project and assign issues to you where appropriate. If you > > > > > create a > > > > github > > > > > account now, and create an issue at > > > > > https://github.com/simh/simh/issues > > > > > describing the problems with Map_WriteW, I'll assign that issue > > > > > to you > > > > and > > > > > when you ultimately submit fixes, the pull request you create > > > > > can be the > > > > fix > > > > > to the issue... > > > > > > > > > > > I suppose I should see about building a current version, as I > > > > > > seem to be in the middle of debugging several things by > > > > > > Braille... (Or is this simply a memory test for me :-) > > > > > > > > > > Without jumping into git, you can always pickup the latest code > > > > > at https://github.com/simh/simh/archive/master.zip > > > > > > > > > > I look forward to anything you've got to offer. > > > > > > > > > > Thanks. > > > > > > > > > > - Mark > > > > > > > > > > > This communication may not represent my employer's views, if > > > > > > any, on the matters discussed. > > > > > > > > > > > > On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote: > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > From toby at telegraphics.com.au Mon May 27 20:54:14 2013 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 27 May 2013 20:54:14 -0400 Subject: [Simh] git branch/cherry-pick - Re: TOPS-20 Source with KMC11 Driver Code? In-Reply-To: <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A35D44.5090601@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578CD@REDROOF2.alohasunset.com> <51A3897F.7020203@ieee.org> <0CC6789C1C831B4C 8CCFF49D45D7010F9E731578D3@REDROOF2.alohasunset.com> <05c601ce5b1a$bcd86a60$36893f20$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DC@REDROOF2.alohasunset.com> <05d001ce5b23$038c9190$0aa5b4b0$@ntlworld.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578DF@REDROOF2.alohasunset.com> <05e301ce5b28$cf2faa30$6d8efe90$@ntlworld.com> Message-ID: <51A40036.6080206@telegraphics.com.au> On 27/05/13 6:23 PM, Robert Jarratt wrote: > Would I be able to check the solution and project files into my own repo and > somehow avoid sending those commits to you, assuming I can keep them > separate from the other changes? > Yes, you can cherry-pick the code-related commits to a branch and make a pull request on that branch only. --Toby From litt at ieee.org Tue May 28 11:54:19 2013 From: litt at ieee.org (Timothe Litt) Date: Tue, 28 May 2013 11:54:19 -0400 Subject: [Simh] KDP Documentation Message-ID: <51A4D32B.60800@ieee.org> I knew I had some documentation for the KMC/DUP combination, though I still haven't found the COMIOP/DUP manual (AA-5670A-TC) in my collection, or on-line. It may be on the -11 or VAX microfiche, but I've contributed my sets to CHM. Don't think they've been digitized. Anyhow, the following memo describes COM IOP-DUP at a high level, and describes in some detail how the KMC controls the DUP. It may be useful for your efforts. One note: "flag mode" as used here has nothing to do with the FLAG character of bit-stuffing protocols. It's a synonym for polled (v.s. interrupt-driven) IO. By the way, there also was COM IOP-DZ, which did similar things with the DZ11. COMMUNICATIONS IOP-DUP COMMUNICATIONS IOP-DUP Page 1-2 INTRODUCTION ------------ The sychronous communications options on the 2020 are comprised of a KMC11 and either one or two DUP11s. This combination can also be referred to as COMM IOP-DUP. The DUP11 forms an interface between a synchronous modem and the UNIBUS. Eight bit bytes of data are transferred to the DUP over the UNIBUS and are serialized and formatted for transmission. The format of the data stream is controlled by registers in the DUP which are read and written by either the CPU or a local IO Processor. (IOP) The 2020 utilizes the KMC11 as the local IOP for the DUP11. The KMC is a microprogrammed auxilliary microprocessor designed for communications functions. The microprogram in the KMC is held in a writable control store memory (CRAM 16 bits x 1K) which is loaded over the UNIBUS by the 2020. This allows changes in protocols etc. to be nearly transparent to the CPU. The KMC transfers data between 2020 memory and the DUP using DMA and NPR transfers. The DUP11 is operated in flag mode (interrupts disabled) and is interrogated by the KMC11 periodically to determine if the character being transmitted is done or if a character has been assembled by the receiver. This relieves the CPU of the extensive interrupt handling which would otherwise be necessary to maintain the synchronous data stream. REFERENCES ---------- 1. KMC11 Users Manual EK-KMC11-OP-001 2. COMM IOP-DUP Programming Manual AA-5670A-TC 3. DSKMA Diagnostic Microfiche AH-E373A-DD 4. DSDUA Diagnostic Microfiche AH-E371A-DD 5. DUP11 Maintenance Manual EK-DUP11-MM-002 6. KS10 Maintenance Guide EK-OKS10-MG-001 7. Terminals and Communications Handbook COMM IOP-DUP Page 1-3 KMC11 The functional operation of the KMC11 is totally dependent on the microcode internal to the unit. Since this microcode is in a writable control store, no attempt will be made to present internal operations of the KMC11 in this course. We will deal with the functional interface between the KMC11, DUP11, and the UNIBUS. The KMC11 has 4 UNIBUS addressable registers. (REFER to Fig. 1) All communications between the CPU and the KMC11 are accomplished using these registers. The KMC11 views these as 8 byte size registers.(BSEL 0-7, addresses 76XXX0-7) They appear to the UNIBUS as 4, word or byte addressable, registers.(SEL 0, 2, 4, and 6) Only the high byte of register SEL 0 (BSEL 1) has a fixed function. This is the Maintenance Register. The remainder of the UNIBUS register functions are controlled by the KMC11 microcode and the CPU software. The Maintenance Register can be used to alter the KMC11 internal data paths for loading the CRAM and for other maintenance functions. For most maintenance functions, the RUN bit of the maintenance Register will be cleared. This stops the microprocessor clock which allows the CPU to manipulate the UNIBUS registers without interference from the KMC11. Bit 10 of the maintenance register ,when set, causes the 10 low order bits of SEL 4 to be used as an address for CRAM. SEL 6 can then be used for either reading or writing the addressed CRAM location. The read or write is controlled by maintenance register bits 10 and 9 + 10 + 13 respectively. To access CRAM, the 2020 CPU will clear the RUN bit of the Maintenance Register. It will then load the desired CRAM address into bits 0 -> 9 of SEL 4. If the operation is to write CRAM, the CPU will load SEL 6 with the new CRAM data and write the Maintenance Register, setting bits 9, 10 and 13. This will cause the KMC11 to write the data in SEL 6 to the CRAM location specified by SEL 4 bits 0 -> 9. To read CRAM, the CPU will write the Maintenance Register bit 10. This will cause the data in the CRAM location specified by bits 0->9 of SEL 4 to be transferred to SEL 6. The CPU will then read SEL 6 to determine the contents of the CRAM location. The Maintenance Register can be used to single step through instructions supplied by the CPU, read CRAM, and single step through the microcode for diagnostic purposes. The KMC11 has its own internal memory (1k x 8 bits) which it uses for data storage and computation. This memory can not be used for instruction storage nor can the CRAM contents be modified by the KMC11. COMM IOP-DUP Page 1-4 KMC11 - UBA - MEMORY DATA TRANSFER The KMC11 receives commands from the CPU through it's UNIBUS registers. The microcode interprets the command and then takes the proper actions to process the command. The KMC11 can also send commands to the CPU by writing it's UNIBUS registers and posting an interrupt to the UNIBUS. There are 3 commands which must occur before transmit and receive operations can take place. 1. INITIALIZATION; This command must be performed after loading KMC11 microcode to initiate operation. 2. A BASE IN command for each DUP11; This command informs the KMC of the line number assignment and CSR base address of each DUP11. 3. A CONTROL IN command for each DUP11; This command sets up the line parameters for each DUP11 and the polling rate to be used in interrogating the DUP CSRs. The COMM IOP-DUP handles the modem handshaking and monitoring with the exception of the RING and CARRIER lines. The COMM IOP-DUP does all of the memory to transmitter and receiver to memory data handling. The CPU informs the COMM IOP-DUP of the areas in memory to be used for transmit and receive data. This is done through BUFFER DESCRIPTOR LISTS for each transmit and receive channel. Each buffer descriptor list points to the start of a series of 3 word (16 bit word length) buffer descriptors in contiguous memory locations. Each buffer descriptor contains; a starting address for the buffer, a byte count, and control fields for the starting and stopping of messages etc.. The buffers may be scattered throughout main memory with the descriptors pointing to them. The major requirement is that the buffer descriptor list be in a series of continuous memory locations. Up to 2 lists may be sent to the KMC11 for each transmit and receive line. The lists are sent to the COMM IOP-DUP when the CPU desires to transmit or receive messages. This is done with a BUFFER ADDRESS IN command. This command has the starting address of the buffer descriptor list, the line number the list applies to, and a bit controlling whether it is a transmit or receive buffer. NOTE The CPU will also have to set up the UBA pager for the buffer areas in memory for address translation from 18 bit UNIBUS to KS10 addressing. The KMC11 uses the buffer descriptor lists to set up it's DMA addressing for each transmit and receive line. Once the lists are in the KMC11, the actual data transfer operations are transparent to the CPU. NOTE All transfers initiated by the KMC11 over the UNIBUS are NPRs. The only time the KMC11 "talks" to the 2020 CPU is when the CPU writes the KMCs registers, or when posting an interrupt on the UNIBUS. COMM IOP-DUP Page 1-5 KMC11 - UBA - MEMORY DATA TRANSFER TRANSMIT -------- NOTE The following description is for DDCMP operation of the COMM IOP-DUP. The CPU will compile the message to be sent in memory and transfer the buffer descriptor list to the KMC11. The KMC11 receives the buffer descriptor list with the command to transmit and retreives the first buffer descriptor from memory. The KMC then does the required handshaking with the modem via the RXCSR register of the DUP11. The KMC initiates the message by setting the SEND bit in TXCSR of the DUP and transferring a SYNC character and the TSOM bit to the TXDBUF. As each character is transferred from the TXDBUF to the transmitter shift register in the DUP, TXDONE will be set in TXCSR. The KMC checks the TXCSR for TXDONE by periodically reading the register. The rate at which the DUP11 registers are polled by the KMC is controlled by one of the set up commands sent to the KMC by the CPU at system initialization. When the KMC detects TXDONE, it will transfer another character to the TXDBUF of the DUP. This will continue until 8 SYNC characters have been transferred, when the KMC will reset the TSOM bit. NOTE The COMM IOP-DUP microcode in the KMC11 can send 8 sync characters automatically in DDCMP mode, depending on a control bit within the buffer descriptor. If the control bit is not set, the sync characters (if any) must be included with the message. At this point the KMC will begin transferring message data from 2020 memory using NPRs. The transfer sequence is similar to the NPR slow mode transfer used for the tape unit, but 36 bit mode is not set. As each data word is received from the system, the KMC places it in it's internal memory and waits for TXDONE to set. When the KMC detects TXDONE on a polling cycle, it transfers an 8 bit character to the DUP TXDBUF register using a byte mode NPR. This process is repeated until the number of characters transferred is equal to the byte count within the buffer descriptor. Depending on the state of control bits in the buffer descriptor , the KMC will either; start transmitting data from a second buffer descriptor or buffer descriptor list and interrupt the CPU , or terminate the message. When the last character of the message is transferred to the DUP, the KMC will set the TEOM bit in the TXCSR. This causes the accumulated CRC to be transmitted immediately after the last character. A second message may start immediately after the first, using another buffer descriptor or buffer descriptor list. Messages may be strung together this way until no buffer descriptor list is pending in the KMC. Alternately, a message may be distributed among several buffer descriptors or descriptor lists, terminating only when the bit, in the buffer descriptor, controlling the setting of the TEOM bit, is set. COMM IOP-DUP Page 1-6 KMC11 - UBA - MEMORY DATA TRANSFER RECEIVE ------- NOTE The following discussion assumes that the COMM IOP-DUP has been initialized and that DDCMP is the protocol. The COMM IOP-DUP receive operation is initiated when the CPU assigns a buffer descriptor list or lists to a receive line. The buffer descriptor list tells the KMC11 where in memory to place received data. If data is received by the DUP11 and no buffer descriptor list is assigned, the COMM IOP-DUP will post an error to the CPU via an interrupt. When the first non-sync character is received and in the RXDBUF, the DUP11 sets RXDONE. This is detected by the KMC11 on the next polling cycle and the character is transferred to the KMC with a byte mode NPR. If the first character following the leading sync characters is not an SOH, ENQ or DLE character the associated DUP11 is resynchronized. In this case no interrupt is sent to the CPU. The KMC will assemble the characters into 16 bit words for transfer to main memory. As each word is assembled, the KMC will issue an NPR transfer, through the UBA, to main memory. The transfer sequence resembles the NPR slow mode transfers used for tape system data transfer with 36 bit mode disabled. The first six bytes in DDCMP protocol are the HEADER. This is treated as a discrete message by the hardware and CRC is done on these six bytes. If a header CRC error occurs, the KMC aborts reception, posts an error interrupt to the CPU, and resumes searching for sync characters. The HEADER is analyzed by the KMC11 for the BYTE COUNT and the DDCMP quick sync bit. The byte count allows the KMC to discern the message CRC characters from the last data character in the message. If the quick sync bit is set, the KMC will place the applicable DUP11 in sync search mode immediately following the end of the message. If the quick sync bit is not set, the KMC11 assumes the next message is either abutted to the current message or is preceded by at least 8 sync characters. The KMC will continue transferring data from the DUP at each assertion of RXDONE, assembling 16 bit words, and transferring the words to memory until the number of bytes received equals the byte count in the header. The KMC11 will not post a completion interrupt to the CPU until the entire message has been received unless the message is larger than the currently assigned message buffer. If the message is larger than the current buffer, the KMC will post an interrupt to the CPU and continue transferring data to the next buffer defined in the buffer descriptor list. When the last character of the message has been received, the KMC will check the CRC and do one of three things: 1. If CRC was bad, the KMC will post an error interrupt to the CPU and immediately enter sync search mode. 2. If CRC was good and the quick sync bit was set in the header, the KMC will start looking for another message preceded by less than 8 sync characters. 3. If CRC was good and the quick sync bit wasn't set, the KMC will examine the next character after the CRC and, if it is a start of header (SOH), continue reception of the next message, placing the data in the next buffer. COMM IOP-DUP Page 1-7 KMC11 - UBA - MEMORY DATA TRANSFER There are two output commands issued by the KMC11 to the CPU. The first is a CONTROL OUT command and is used in posting error conditions to the CPU. The second is the BUFFER ADDRESS OUT command used to indicate that that a buffer assigned by a buffer descriptor has been filled or its' contents transmitted. The buffer address out command is also used when a complete message has been received, whether or not it has filled a buffer. In any case, the KMC will shift its' memory NPR operations to the next buffer in the buffer descriptor list or to the next buffer descriptor list as applicable. COMM IOP-DUP Page 1-8 DUP11 INTRODUCTION ------------ The DUP11, together with the KMC11, forms a synchronous communications subsystem for the 2020. High speed synchronous communications capability allows the 2020 to be used in computer networking applications such as DECNET. This type of application may be a major factor in a buyer's decision on which computer system he will purchase. BASIC BLOCK FUNCTIONS --------------------- The DUP11 basic block can be broken down into three major areas; 1. THE UNIBUS INTERFACE comprised of the UNIBUS tranceivers, the interrupt control logic, the address select logic, the reset logic, and the UNIBUS multiplexer. 2. THE REGISTERS AND CONTROL LOGIC comprised of the five registers and part of the TX control and RX control logic. 3. THE MODEM INTERFACE comprised of the remainder of the TX control and RX control logic and the clock logic. UNIBUS INTERFACE ---------------- This section of the DUP11 is responsible for getting data into and out of the unit to the UNIBUS. The address select logic decodes the UNIBUS address lines and determines if the address on the lines matches the switch settings on the DUP11 and what type of data cycle is required. The interrupt control logic will issue a BR when conditions internal to the DUP11 require processor intervention. The interrupt logic can be enabled or disabled under software control. The reset logic initializes the DUP11 when a UNIBUS initialize signal occurs. The reset logic will also initialize the DUP11 under software control when TXCSR bit 8 is set. The UNIBUS tranceivers and multiplexer receive and transmit data between the UNIBUS and the DUP11 registers under control of the address select logic. DUP11 REGISTERS --------------- There are 5 registers in the DUP11 which are used to control it's operation and communicate with the UNIBUS. 1. The RXCSR register is used to control the operation of the receiver section of the DUP11 and to interface with the modem. The register is R/W and is word and byte addressable. 2. The RXDBUF is a read only register which holds the received data in the low byte and status information in the high byte. The RXDBUF shares the same address with PACSR and is word addressable. 3. The PACSR is a write only register which controls the overall mode of the DUP11. This register contains the DEC mode bit, the bit which determines whether CRC is to be used or not, the secondary address mode bit, and either the secondary address or the SYNC character in the low byte. The PACSR and the RXDBUF share the same address and are word addressable only. COMM IOP-DUP Page 1-9 DUP11 4. The TXCSR register is used to control the operation of the transmitter section of the DUP11 and to control maintenance functions. The register is read/write and word and byte addressable. 5. The TXDBUF register contains the remainder of the control and status bits for the transmitter and the low byte holds the data to be transmitted. The register is word and byte addressable and is a read/write register. TX CONTROL LOGIC ---------------- The transmit control logic is responsible for: 1. Serializing data to be transmitted and transferring it to the modem. 2. Transmission of FLAG and ABORT sequences in bit oriented protocols. (DEC MODE reset) 3. Bit stuffing when in bit oriented protocols. 4. Signaling when the character currently being transmitted is done by setting TXDONE in TXCSR. 5. Computing CRC in either CRC-16 or CRC/CCITT format on transmitted data. RX CONTROL LOGIC ---------------- The receiver control logic is responsible for: LE;Synchronizing the receiver logic with the received signal. 1. Assembling the received serial data in the receiver shift register and transferring it to the RXDBUF. 2. Signaling when the latest assembled character is available in the RXDBUF by asserting RXDONE. 3. "Stripping" extra leading SYNC characters after synchronization when in DEC mode. LE;Deleting "stuffed" "0" bits from the data stream when not in DEC mode. 4. Detecting FLAG and ABORT sequences when not in DEC mode. 5. Checking received CRC characters against computed CRC characters in CRC-16 or CRC/CCITT formats. FUNCTIONAL DESCRIPTION ---------------------- The transmit operation of the DUP11 is somewhat dependent on whether a bit oriented protocol (SDLC type protocols) or a byte oriented protocol (DDCMP etc.) is being used. BYTE ORIENTED OPERATION (DDCMP and BISYNC) ------------------------------------------ For byte mode operation the DEC mode bit in PACSR must be set. This will cause the CRC circuits to use the CRC/16 format to check and generate CRC. This bit also controls whether "0" bits are "stuffed" into or stripped from a data stream containing more than 5 consecutive "1" bits. When the DEC mode bit is set, bit stuffing is not done. COMM IOP-DUP Page 1-10 DUP11 The CRC PAR INH bit in PACSR is used to enable or disable CRC generation or error detection. This bit will usually be set on BISYNC protocols and reset for DDCMP. All "handshaking" with the modem must be completed prior to the start of transmission. This is done through the RXCSR register. The "handshaking" is not automatic and must be done by the program. The insertion of Sync characters is also a program function. The DUP11 has no provision for automatically transmitting sync characters. Transmission begins when the program sets the SEND bit in TXCSR and loads a sync character into the TXDBUF along with the Transmit Start Of Message bit. All sync characters must be loaded by the program and the TSOM bit held asserted until the start of the last sync character. As each character is sent out, the TXDONE bit is set in TXCSR. The program will get another sync character, load it into TXDBUF and repeat until the proper number of sync characters have been sent. After the start of the last sync character the program will clear TSOM. At the next assertion of TXDONE the first data character will be loaded into TXDBUF and the CRC circuit will start to compute the CRC code for the data portion of the message. NOTE The CRC calculation can be inhibited by bit 09 of PACSR. This will usually be the case for BISYNC type protocols. The program will continue to load characters into the TXDBUF, at each transition of TXDONE, until the end of the message. When the last character is loaded, the TEOM bit will also be set by the program. This will cause the CRC check character to be transmitted immediately following the last data character. (If the CRC is enabled) BIT ORIENTED OPERATION (SDLC etc.) ---------------------------------- For operation in SDLC or other bit oriented protocols the DEC MODE bit in PACSR must be reset. This allows bit stuffing (The insertion of a "0" bit after each 5 consecutive "1" bits in a data stream of more than 5 consecutive "1" bits) to prevent confusing data with FLAG and ABORT sequences. The DEC MODE bit being reset also alters the CRC computation so that the CRC conforms to CRC/CCITT format. Some protocols may compute the CRC differently and if one of those is in use the CRC will be disabled using bit 09 of PARCSR. If CRC is disabled the program must compute any required CRC for the protocol in use. NOTE The following discussion assumes that all required "handshaking" with the modem has been completed and the DUP11 has been initialized. To start transmission, the SEND bit must be set in TXCSR and the TSOM bit in TXDBUF. This will cause an initial FLAG character to be transmitted. FLAGs will continue to be transmitted until the TSOM bit is reset. The transmission of FLAG characters in this mode is automatic and the characters do not have to be loaded into the TXDBUF by the processor. When the TSOM bit is reset, the TXDONE bit will be asserted at the conclusion of the character in transmission. COMM IOP-DUP Page 1-11 DUP11 When the program "sees" TXDONE, it will start transferring data to the TXDBUF. At each assertion of TXDONE, another character of data will be loaded. The CRC computation (if enabled) starts with the transfer of the first data to TXDBUF. The transmitter also enters the "transparent" state (bit stuffing is enabled) when the transmitter starts sending data. At the conclusion of the message the program sets the TEOM bit in TXDBUF and, at the end of the character being serialized, (if CRC is enabled) the CRC character is transmitted. At the conclusion of the CRC character a FLAG character is automatically transmitted. The program has three options at this point: SEND may be cleared, which allows the FLAG character to be completed and after a delay of 1 1/2 bit times the transmitter enters the IDLE state. TEOM may be held set, which will cause continuous FLAG characters to be transmitted. TEOM may be cleared and a second data message started without setting TSOM. The receiver section operates differently for byte oriented and bit oriented protocols and the two modes are discussed separately in the following section. BYTE ORIENTED RECEIVER (DDCMP, BISYNC etc.) ------------------------------------------- For BYTE mode operation, the DEC MODE bit and the SYNC character to be used must be loaded into the PACSR prior to enabling the receiver. The DEC MODE bit causes the low byte of PACSR to be recognized as a SYNC character, and the CRC circuitry of both the receiver and transmitter to use CRC-16 for generating and checking CRC. The STRIP SYNC bit of RXCSR may also be set, which allows SYNC characters occuring after receiver synchronization to be automatically deleted. Synchronization is considered complete when 2 succesive characters which match the low byte of PACSR have been recognized. The STRIP SYNC bit causes any other leading SYNC characters to be ignored. After the initialization and any needed modem handshaking has been done, the RCVEN bit in RXCSR may be set. This enables the receiver to search the incoming signals until 2 successive SYNC characters are detected. All characters following the detection of the 2 successive SYNC characters are interpreted as data. (Unless the STRIP SYNC bit is set, when it is the detection of the first non-SYNC character that will cause all following characters to be interpreted as data.) When this has occured, the RXACT bit will be asserted and the RXDONE bit set. (Also this will disable the STRIP SYNC logic until the receiver logic is reinitialized.) All data following the SYNC characters is included in the CRC calculation. For some protocols in the BISYNC family the CRC logic must be disabled due to possible control characters in the data field. Once RXDONE is set the program will read the assembled character in the RXBUF, reseting RXDONE. This process will repeat until the expected number of characters has been received. The program will then sample the CRC PAR ERR bit to determine if there was an error in the data received. (If CRC was enabled) After the CRC is sampled, the RCVEN bit will be cleared to reinitialize the receiver. At this point the entire process may repeat to receive another message. BIT MODE RECEIVE OPERATION (SDLC etc.) -------------------------------------- For SDLC family protocols the DEC MODE bit must be reset. This changes the CRC checking to CRC/CCITT and enables the "stuffed" "0" bits in the data stream to be stripped out, restoring the original data. The "0" bits were originally inserted to avoid confusion of data with FLAG or ABORT characters. These characters are detected by the DUP11 when the DEC MODE bit is not set. COMM IOP-DUP Page 1-12 DUP11 The reset DEC MODE bit also causes a different function to be assigned to the low byte of PACSR. This byte may be used as a secondary station address for protocols supporting this option. This is under the control of bit 12 of PACSR. After initialization and any necessary handshaking with the modem, the RCVEN bit is set. After this bit is set, the receiver searches the incoming data for FLAG characters. If the receiver is operating in the primary mode, all data subsequent to the last initial FLAG character is presented to the program. The RSOM bit is set with the reception of the initial data character and RXDONE is set when the data is in the RXDBUF. If the receiver is in the secondary address mode, the character immediately following the last initial FLAG is compared with the low byte of PACSR. If the character matches the contents of that byte, the character immediately following is taken as the start of the data field and TSOM is set. If the contents do not match, the receiver resumes looking for FLAG characters and TSOM is not set. When the start of the data field is detected, RXACT is set in RXCSR. The data continues to be assembled (with any "stuffed" zeros removed) and transferred to the RXDBUF with each transfer setting RXDONE. The program reads the data from RXDBUF (which resets RXDONE) with each assertion of RXDONE. This process continues until the detection of a FLAG character which signifies the end of the message. The detection of the FLAG will cause REOM and RXDONE to set. The contents of the RXDBUF is invalid when REOM is set. If CRC checking is enabled, the check will be valid only when REOM is set. The entire contents of the message between the FLAG characters is included in the CRC check. INTERRUPT OPERATION -------------------- The DUP11 can be operated in two modes; flag mode, and interrupt mode. In flag mode, the DUP11 does not interrupt the processor. The RXCSR and TXCSR must be interrogated to determine the state of the respective DONE bits and the modem control or status bits. The interrogation must occur often enough to ensure that characters are removed from, or written into, the respective DBUF without causing data late or overrun conditions. In the interrupt mode, the DUP11 interrupts the processor when either DONE bit is set and when the modem changes status. There are two discrete types of interrupt which generate different vector addresses. Receiver and data set interrupts generate vector adress XX0. Transmitter interrupts generate vector address XX4. The XX portion of the vector is switch selectable. Whether the DUP11 is in interrupt or flag mode is determined by bits 5 and 6 of RXCSR and bit 6 of TXCSR. These are the interrupt enable bits. Bit 5 of RXCSR controls data set interrupts. Bit 6 of RXCSR and TXCSR control receiver and transmitter interrupts respectively. When each of these bits are set, the corresponding interrupt is enabled. Receiver and transmitter interrupts are initiated by the RXDONE and TXDONE bits respectively. If a DONE bit is set by the DUP11, and the corresponding interrupt is enabled, an interrupt is gated to the UNIBUS. In the 2020 the DUP11 is operated in the flag mode for data communications. The servicing of the DUP11 registers is done by the KMC11 which relieves the KS10 CPU of the overhead. In diagnostics for the DUP11 on the KS10 the DUP11 is operated in the interrupt mode. -- This communication may not represent my employer's views, if any, on the matters discussed. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From jg at jordi.guillaumes.name Tue May 28 17:39:21 2013 From: jg at jordi.guillaumes.name (Jordi Guillaumes i Pons) Date: Tue, 28 May 2013 23:39:21 +0200 Subject: [Simh] DUP on simh In-Reply-To: <51A4D32B.60800@ieee.org> References: <51A4D32B.60800@ieee.org> Message-ID: <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Congratulations (and thank-yous) for anyone involved in this new enhancement :) Of course, I could not resist the temptation of giving it a try. So I have cloned my TOPS-10 installation and have MONGENed it with DUP support. First problem: If I select DECNET support I get a lot of undefined symbols UNLESS I select to include also ANF-10 support. I have to supose this is intended. And second problem: BOOT>[1,5]newsys.exe [Loading from DSKC:NEWSYS.EXE[1,5]] BTES11 28-May-13 Why reload: new Date: Time: ?Stopcode EMA, type=STOP, on CPU0 at 28-May-113 23:34:59 CPU Status Block APRID = 470130,,010001 CONI APR, = 001060,,000070 CONI PI, = 000000,,000271 CONI PAG, = 000000,,060002 DATAI PAG, = 500100,,000004 Reload monitor [Dumping on DSKC:CRASH.EXE[1,4]] Boom! My lack of knowledge prevents me to investigate further by now :) Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES From Mark at infocomm.com Tue May 28 17:47:37 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Tue, 28 May 2013 14:47:37 -0700 Subject: [Simh] DUP on simh In-Reply-To: <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> References: <51A4D32B.60800@ieee.org> <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157902@REDROOF2.alohasunset.com> On Tuesday, May 28, 2013 at 2:39 PM, Jordi Guillaumes i Pons wrote: > Congratulations (and thank-yous) for anyone involved in this new > enhancement :) This is a work in progress. It does not yet work reliably in the basic PDP11 to PDP11 case. I'm still debugging this. > Of course, I could not resist the temptation of giving it a try. So I have cloned > my TOPS-10 installation and have MONGENed it with DUP support. > > First problem: If I select DECNET support I get a lot of undefined symbols > UNLESS I select to include also ANF-10 support. I have to supose this is > intended. I have no idea if a bare DUP11 was ever supported in TOPS10. The KMC/DUP combination devices worked together (the KMC controlled the DUP). We haven't gotten that far yet. Rob Jarratt has been working on the KMC and his work hasn't stabilized yet either. I'll let you know when things are in better shape. - Mark From b4 at gewt.net Tue May 28 19:12:07 2013 From: b4 at gewt.net (Cory Smelosky) Date: Tue, 28 May 2013 23:12:07 -0000 Subject: [Simh] DUP on simh References: <51A4D32B.60800@ieee.org> <4A3C2569-7CF8-4BA9-91D5-F794E21BF597@jordi.guillaumes.name> Message-ID: On Tue, 28 May 2013, Jordi Guillaumes i Pons wrote: > > > Congratulations (and thank-yous) for anyone involved in this new enhancement :) > > Of course, I could not resist the temptation of giving it a try. So I have cloned my TOPS-10 installation and have MONGENed it with DUP support. > > First problem: If I select DECNET support I get a lot of undefined symbols UNLESS I select to include also ANF-10 support. I have to supose this is intended. DECnet front end. Don't need the ANF-10 > > And second problem: > > BOOT>[1,5]newsys.exe > [Loading from DSKC:NEWSYS.EXE[1,5]] > > BTES11 28-May-13 > Why reload: new > Date: > Time: > > ?Stopcode EMA, type=STOP, on CPU0 at 28-May-113 23:34:59 > > > CPU Status Block > > APRID = 470130,,010001 > CONI APR, = 001060,,000070 > CONI PI, = 000000,,000271 > CONI PAG, = 000000,,060002 > DATAI PAG, = 500100,,000004 > Reload monitor > [Dumping on DSKC:CRASH.EXE[1,4]] > > Boom! My lack of knowledge prevents me to investigate further by now :) > Install the 7.05 update. > > Jordi Guillaumes i Pons > jg at jordi.guillaumes.name > HECnet: BITXOV::JGUILLAUMES > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Cory Smelosky http://gewt.net/ Personal stuff http://gimme-sympathy.org Experiments From Mark at infocomm.com Wed May 29 11:39:14 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 29 May 2013 08:39:14 -0700 Subject: [Simh] KDP Documentation In-Reply-To: <51A4D32B.60800@ieee.org> References: <51A4D32B.60800@ieee.org> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> Hi Tim, On Tuesday, May 28, 2013 at 8:54 AM, Timothe Litt wrote: > I knew I had some documentation for the KMC/DUP combination, though I > still haven't found the COMIOP/DUP manual (AA-5670A-TC) in my > collection, or on-line. It may be on the -11 or VAX microfiche, but > I've contributed my sets to CHM. Don't think they've been digitized. > > Anyhow, the following memo describes COM IOP-DUP at a high level, and > describes in some detail how the KMC controls the DUP. It may be useful > for your efforts. One note: "flag mode" as used here has nothing to do > with the FLAG character of bit-stuffing protocols. It's a synonym for > polled (v.s. interrupt-driven) IO. > > By the way, there also was COM IOP-DZ, which did similar things with the > DZ11. Thanks for this. I've got a couple of questions for you or anyone else: 1) The below document mentions the possibility of one or two DUPs related to a single KMC. What tells the KMC which DUP it is to exchange data with, and how does it know the DUP's bus address? 2) You had mentioned previously that the host OS doesn't interact with the DUP device except for a possible initial device probe testing for NXM, and then writing zeros to the registers. What would happen if the OS didn't find/see the DUP at all? 3) How many KMC/DUP devices would work on a given Unibus if there were no power limitations (i.e. how many devices could the OS software interact with)? 4) Was there software support for talking to a bare DUP without a related KMC in any PDP10 operating systems? 5) Was this KMC/DUP combination ever a supported device on PDP11 or VAX systems? Thanks. - Mark > COMMUNICATIONS IOP-DUP > > > > > COMMUNICATIONS IOP-DUP > Page 1-2 > > > INTRODUCTION > ------------ > > > > > The sychronous communications options on the 2020 are comprised of a > KMC11 and either one or two DUP11s. This > combination can also be referred to as COMM IOP-DUP. > > The DUP11 forms an interface between a synchronous modem and the > UNIBUS. Eight bit bytes of data are transferred to > the DUP over the UNIBUS and are serialized and formatted for transmission. > The format of the data stream is controlled by > registers in the DUP which are read and written by either the CPU or a local > IO Processor. (IOP) > > The 2020 utilizes the KMC11 as the local IOP for the DUP11. The KMC is a > microprogrammed auxilliary microprocessor > designed for communications functions. The microprogram in the KMC is > held in a writable control store memory (CRAM 16 > bits x 1K) which is loaded over the UNIBUS by the 2020. This allows changes > in protocols etc. to be nearly transparent > to the CPU. > > The KMC transfers data between 2020 memory and the DUP using DMA > and NPR transfers. The DUP11 is operated in flag > mode (interrupts disabled) and is interrogated by the KMC11 periodically to > determine if the character being transmitted > is done or if a character has been assembled by the receiver. This relieves > the CPU of the extensive interrupt handling > which would otherwise be necessary to maintain the synchronous data > stream. > > > > REFERENCES > ---------- > > > > 1. KMC11 Users Manual EK-KMC11-OP-001 > > 2. COMM IOP-DUP Programming Manual AA-5670A-TC > > 3. DSKMA Diagnostic Microfiche AH-E373A-DD > > 4. DSDUA Diagnostic Microfiche AH-E371A-DD > > 5. DUP11 Maintenance Manual EK-DUP11-MM-002 > > 6. KS10 Maintenance Guide EK-OKS10-MG-001 > > 7. Terminals and Communications Handbook > > > COMM IOP-DUP Page 1-3 > KMC11 > > > The functional operation of the KMC11 is totally dependent on the > microcode internal to the unit. Since this > microcode is in a writable control store, no attempt will be made to > present internal operations of the KMC11 in this > course. We will deal with the functional interface between the KMC11, > DUP11, and the UNIBUS. > > The KMC11 has 4 UNIBUS addressable registers. (REFER to Fig. 1) All > communications between the CPU and the KMC11 > are accomplished using these registers. The KMC11 views these as 8 byte > size registers.(BSEL 0-7, addresses 76XXX0-7) > They appear to the UNIBUS as 4, word or byte addressable, registers.(SEL 0, > 2, 4, and 6) > > Only the high byte of register SEL 0 (BSEL 1) has a fixed function. This is > the Maintenance Register. The remainder > of the UNIBUS register functions are controlled by the KMC11 microcode and > the CPU software. > > The Maintenance Register can be used to alter the KMC11 internal data > paths for loading the CRAM and for other > maintenance functions. > > For most maintenance functions, the RUN bit of the maintenance > Register will be cleared. This stops the > microprocessor clock which allows the CPU to manipulate the UNIBUS > registers without interference from the KMC11. > > Bit 10 of the maintenance register ,when set, causes the 10 low order bits > of SEL 4 to be used as an address for > CRAM. SEL 6 can then be used for either reading or writing the addressed > CRAM location. The read or write is controlled > by maintenance register bits 10 and 9 + 10 + 13 respectively. > > To access CRAM, the 2020 CPU will clear the RUN bit of the Maintenance > Register. It will then load the desired CRAM > address into bits 0 -> 9 of SEL 4. If the operation is to write CRAM, the CPU > will load SEL 6 with the new CRAM data and > write the Maintenance Register, setting bits 9, 10 and 13. This will cause the > KMC11 to write the data in SEL 6 to the > CRAM location specified by SEL 4 bits 0 -> 9. To read CRAM, the CPU will > write the Maintenance Register bit 10. This > will cause the data in the CRAM location specified by bits 0->9 of SEL 4 to be > transferred to SEL 6. The CPU will then > read SEL 6 to determine the contents of the CRAM location. > > The Maintenance Register can be used to single step through instructions > supplied by the CPU, read CRAM, and single > step through the microcode for diagnostic purposes. > > The KMC11 has its own internal memory (1k x 8 bits) which it uses for data > storage and computation. This memory can > not be used for instruction storage nor can the CRAM contents be modified > by the KMC11. > > > > COMM IOP-DUP Page 1-4 > KMC11 - UBA - MEMORY DATA TRANSFER > > > The KMC11 receives commands from the CPU through it's UNIBUS registers. > The microcode interprets the command and then > takes the proper actions to process the command. The KMC11 can also > send commands to the CPU by writing it's UNIBUS > registers and posting an interrupt to the UNIBUS. > > There are 3 commands which must occur before transmit and receive > operations can take place. > > > 1. INITIALIZATION; This command must be performed after loading > KMC11 microcode to initiate operation. > > > 2. A BASE IN command for each DUP11; This command informs the KMC > of the line number assignment and CSR base > address of each DUP11. > > > 3. A CONTROL IN command for each DUP11; This command sets up the > line parameters for each DUP11 and the polling > rate to be used in interrogating the DUP CSRs. > > > > The COMM IOP-DUP handles the modem handshaking and monitoring with > the exception of the RING and CARRIER lines. The COMM > IOP-DUP does all of the memory to transmitter and receiver to memory > data handling. The CPU informs the COMM IOP-DUP of > the areas in memory to be used for transmit and receive data. This is done > through BUFFER DESCRIPTOR LISTS for each > transmit and receive channel. > > Each buffer descriptor list points to the start of a series of 3 word (16 bit > word length) buffer descriptors in > contiguous memory locations. Each buffer descriptor contains; a starting > address for the buffer, a byte count, and > control fields for the starting and stopping of messages etc.. The buffers may > be scattered throughout main memory with > the descriptors pointing to them. > > The major requirement is that the buffer descriptor list be in a series of > continuous memory locations. Up to 2 > lists may be sent to the KMC11 for each transmit and receive line. The lists > are sent to the COMM IOP-DUP when the CPU > desires to transmit or receive messages. > > This is done with a BUFFER ADDRESS IN command. This command has the > starting address of the buffer descriptor list, > the line number the list applies to, and a bit controlling whether it is a > transmit or receive buffer. > > > NOTE > > The CPU will also have to set up the UBA pager for the buffer areas in > memory for address > translation from 18 bit UNIBUS to KS10 addressing. > > > > The KMC11 uses the buffer descriptor lists to set up it's DMA addressing > for each transmit and receive line. Once > the lists are in the KMC11, the actual data transfer operations are transparent > to the CPU. > > > NOTE > > All transfers initiated by the KMC11 over the UNIBUS are NPRs. The > only time the KMC11 > "talks" to the 2020 CPU is when the CPU writes the KMCs > registers, or when posting an > interrupt on the UNIBUS. > > > > COMM IOP-DUP Page 1-5 > KMC11 - UBA - MEMORY DATA TRANSFER > > > TRANSMIT > -------- > > > NOTE > > The following description is for DDCMP operation of the COMM IOP- > DUP. > > > > The CPU will compile the message to be sent in memory and transfer the > buffer descriptor list to the KMC11. > > The KMC11 receives the buffer descriptor list with the command to > transmit and retreives the first buffer descriptor > from memory. The KMC then does the required handshaking with the > modem via the RXCSR register of the DUP11. The KMC > initiates the message by setting the SEND bit in TXCSR of the DUP and > transferring a SYNC character and the TSOM bit to > the TXDBUF. > > As each character is transferred from the TXDBUF to the transmitter shift > register in the DUP, TXDONE will be set in > TXCSR. The KMC checks the TXCSR for TXDONE by periodically reading the > register. > > The rate at which the DUP11 registers are polled by the KMC is controlled > by one of the set up commands sent to the > KMC by the CPU at system initialization. > > When the KMC detects TXDONE, it will transfer another character to the > TXDBUF of the DUP. This will continue until 8 > SYNC characters have been transferred, when the KMC will reset the TSOM > bit. > > > NOTE > > The COMM IOP-DUP microcode in the KMC11 can send 8 sync > characters automatically in DDCMP > mode, depending on a control bit within the buffer descriptor. If > the control bit is not > set, the sync characters (if any) must be included with the message. > > > > At this point the KMC will begin transferring message data from 2020 > memory using NPRs. The transfer sequence is > similar to the NPR slow mode transfer used for the tape unit, but 36 bit mode > is not set. > > As each data word is received from the system, the KMC places it in it's > internal memory and waits for TXDONE to set. > When the KMC detects TXDONE on a polling cycle, it transfers an 8 bit > character to the DUP TXDBUF register using a byte > mode NPR. > > This process is repeated until the number of characters transferred is > equal to the byte count within the buffer > descriptor. Depending on the state of control bits in the buffer descriptor , > the KMC will either; start transmitting > data from a second buffer descriptor or buffer descriptor list and interrupt > the CPU , or terminate the message. > > When the last character of the message is transferred to the DUP, the > KMC will set the TEOM bit in the TXCSR. This > causes the accumulated CRC to be transmitted immediately after the last > character. > > A second message may start immediately after the first, using another > buffer descriptor or buffer descriptor list. > Messages may be strung together this way until no buffer descriptor list is > pending in the KMC. Alternately, a message > may be distributed among several buffer descriptors or descriptor lists, > terminating only when the bit, in the buffer > descriptor, controlling the setting of the TEOM bit, is set. > > COMM IOP-DUP Page 1-6 > KMC11 - UBA - MEMORY DATA TRANSFER > > > RECEIVE > ------- > > > NOTE > > The following discussion assumes that the COMM IOP-DUP has been > initialized and that DDCMP > is the protocol. > > > > The COMM IOP-DUP receive operation is initiated when the CPU assigns a > buffer descriptor list or lists to a receive > line. The buffer descriptor list tells the KMC11 where in memory to place > received data. If data is received by the > DUP11 and no buffer descriptor list is assigned, the COMM IOP-DUP will post > an error to the CPU via an interrupt. > > When the first non-sync character is received and in the RXDBUF, the > DUP11 sets RXDONE. This is detected by the > KMC11 on the next polling cycle and the character is transferred to the KMC > with a byte mode NPR. > > If the first character following the leading sync characters is not an SOH, > ENQ or DLE character the associated DUP11 > is resynchronized. In this case no interrupt is sent to the CPU. > > The KMC will assemble the characters into 16 bit words for transfer to > main memory. As each word is assembled, the > KMC will issue an NPR transfer, through the UBA, to main memory. The > transfer sequence resembles the NPR slow mode > transfers used for tape system data transfer with 36 bit mode disabled. > > The first six bytes in DDCMP protocol are the HEADER. This is treated as a > discrete message by the hardware and CRC > is done on these six bytes. If a header CRC error occurs, the KMC aborts > reception, posts an error interrupt to the CPU, > and resumes searching for sync characters. > > The HEADER is analyzed by the KMC11 for the BYTE COUNT and the > DDCMP quick sync bit. The byte count allows the KMC > to discern the message CRC characters from the last data character in the > message. If the quick sync bit is set, the KMC > will place the applicable DUP11 in sync search mode immediately following > the end of the message. If the quick sync bit > is not set, the KMC11 assumes the next message is either abutted to the > current message or is preceded by at least 8 sync > characters. > > The KMC will continue transferring data from the DUP at each assertion of > RXDONE, assembling 16 bit words, and > transferring the words to memory until the number of bytes received equals > the byte count in the header. > > The KMC11 will not post a completion interrupt to the CPU until the entire > message has been received unless the > message is larger than the currently assigned message buffer. If the > message is larger than the current buffer, the KMC > will post an interrupt to the CPU and continue transferring data to the next > buffer defined in the buffer descriptor list. > > When the last character of the message has been received, the KMC will > check the CRC and do one of three things: > > 1. If CRC was bad, the KMC will post an error interrupt to the CPU and > immediately enter sync search mode. > > 2. If CRC was good and the quick sync bit was set in the header, the KMC > will start looking for another message > preceded by less than 8 sync characters. > > 3. If CRC was good and the quick sync bit wasn't set, the KMC will examine > the next character after the CRC and, if > it is a start of header (SOH), continue reception of the next message, > placing the data in the next buffer. > > > COMM IOP-DUP Page 1-7 > KMC11 - UBA - MEMORY DATA TRANSFER > > > There are two output commands issued by the KMC11 to the CPU. The > first is a CONTROL OUT command and is used in > posting error conditions to the CPU. The second is the BUFFER ADDRESS > OUT command used to indicate that that a buffer > assigned by a buffer descriptor has been filled or its' contents transmitted. > The buffer address out command is also used > when a complete message has been received, whether or not it has filled a > buffer. In any case, the KMC will shift its' > memory NPR operations to the next buffer in the buffer descriptor list or > to the next buffer descriptor list as > applicable. > > > COMM IOP-DUP Page 1-8 > DUP11 > > > INTRODUCTION > ------------ > > > The DUP11, together with the KMC11, forms a synchronous > communications subsystem for the 2020. High speed > synchronous communications capability allows the 2020 to be used in > computer networking applications such as DECNET. This > type of application may be a major factor in a buyer's decision on which > computer system he will purchase. > > BASIC BLOCK FUNCTIONS > --------------------- > > The DUP11 basic block can be broken down into three major areas; > > 1. THE UNIBUS INTERFACE comprised of the UNIBUS tranceivers, the > interrupt control logic, the address select logic, > the reset logic, and the UNIBUS multiplexer. > > 2. THE REGISTERS AND CONTROL LOGIC comprised of the five registers > and part of the TX control and RX control logic. > > 3. THE MODEM INTERFACE comprised of the remainder of the TX control > and RX control logic and the clock logic. > > UNIBUS INTERFACE > ---------------- > > > This section of the DUP11 is responsible for getting data into and out of > the unit to the UNIBUS. The address select > logic decodes the UNIBUS address lines and determines if the address on the > lines matches the switch settings on the DUP11 > and what type of data cycle is required. > > The interrupt control logic will issue a BR when conditions internal to the > DUP11 require processor intervention. > The interrupt logic can be enabled or disabled under software control. > > The reset logic initializes the DUP11 when a UNIBUS initialize signal occurs. > The reset logic will also initialize > the DUP11 under software control when TXCSR bit 8 is set. > > The UNIBUS tranceivers and multiplexer receive and transmit data > between the UNIBUS and the DUP11 registers under > control of the address select logic. > > DUP11 REGISTERS > --------------- > > There are 5 registers in the DUP11 which are used to control it's operation > and communicate with the UNIBUS. > > 1. The RXCSR register is used to control the operation of the receiver > section of the DUP11 and to interface with > the modem. The register is R/W and is word and byte addressable. > > 2. The RXDBUF is a read only register which holds the received data in the > low byte and status information in the > high byte. The RXDBUF shares the same address with PACSR and is > word addressable. > > 3. The PACSR is a write only register which controls the overall mode of > the DUP11. This register contains the DEC > mode bit, the bit which determines whether CRC is to be used or not, > the secondary address mode bit, and either > the secondary address or the SYNC character in the low byte. The > PACSR and the RXDBUF share the same address and > are word addressable only. > > COMM IOP-DUP Page 1-9 > DUP11 > > > 4. The TXCSR register is used to control the operation of the transmitter > section of the DUP11 and to control > maintenance functions. The register is read/write and word and byte > addressable. > > 5. The TXDBUF register contains the remainder of the control and status > bits for the transmitter and the low byte > holds the data to be transmitted. The register is word and byte > addressable and is a read/write register. > > TX CONTROL LOGIC > ---------------- > > The transmit control logic is responsible for: > > 1. Serializing data to be transmitted and transferring it to the modem. > > 2. Transmission of FLAG and ABORT sequences in bit oriented protocols. > (DEC MODE reset) > > 3. Bit stuffing when in bit oriented protocols. > > 4. Signaling when the character currently being transmitted is done by > setting TXDONE in TXCSR. > > 5. Computing CRC in either CRC-16 or CRC/CCITT format on transmitted > data. > > RX CONTROL LOGIC > ---------------- > > The receiver control logic is responsible for: > LE;Synchronizing the receiver logic with the received signal. > > 1. Assembling the received serial data in the receiver shift register and > transferring it to the RXDBUF. > > 2. Signaling when the latest assembled character is available in the > RXDBUF by asserting RXDONE. > > 3. "Stripping" extra leading SYNC characters after synchronization when in > DEC mode. LE;Deleting "stuffed" "0" bits > from the data stream when not in DEC mode. > > 4. Detecting FLAG and ABORT sequences when not in DEC mode. > > 5. Checking received CRC characters against computed CRC characters in > CRC-16 or CRC/CCITT formats. > > FUNCTIONAL DESCRIPTION > ---------------------- > > > The transmit operation of the DUP11 is somewhat dependent on whether > a bit oriented protocol (SDLC type protocols) or > a byte oriented protocol (DDCMP etc.) is being used. > > BYTE ORIENTED OPERATION (DDCMP and BISYNC) > ------------------------------------------ > > > For byte mode operation the DEC mode bit in PACSR must be set. This will > cause the CRC circuits to use the CRC/16 > format to check and generate CRC. This bit also controls whether "0" bits > are "stuffed" into or stripped from a data > stream containing more than 5 consecutive "1" bits. When the DEC mode bit > is set, bit stuffing is not done. > > COMM IOP-DUP Page 1-10 > DUP11 > > > The CRC PAR INH bit in PACSR is used to enable or disable CRC generation > or error detection. This bit will usually > be set on BISYNC protocols and reset for DDCMP. > > All "handshaking" with the modem must be completed prior to the start > of transmission. This is done through the > RXCSR register. The "handshaking" is not automatic and must be done by the > program. > > The insertion of Sync characters is also a program function. The DUP11 > has no provision for automatically > transmitting sync characters. > > Transmission begins when the program sets the SEND bit in TXCSR and > loads a sync character into the TXDBUF along with > the Transmit Start Of Message bit. All sync characters must be loaded by the > program and the TSOM bit held asserted until > the start of the last sync character. As each character is sent out, the > TXDONE bit is set in TXCSR. The program will > get another sync character, load it into TXDBUF and repeat until the proper > number of sync characters have been sent. > After the start of the last sync character the program will clear TSOM. At the > next assertion of TXDONE the first data > character will be loaded into TXDBUF and the CRC circuit will start to > compute the CRC code for the data portion of the > message. > > > NOTE > > The CRC calculation can be inhibited by bit 09 of PACSR. This will > usually be the case for > BISYNC type protocols. > > > > The program will continue to load characters into the TXDBUF, at each > transition of TXDONE, until the end of the > message. When the last character is loaded, the TEOM bit will also be set by > the program. This will cause the CRC check > character to be transmitted immediately following the last data character. (If > the CRC is enabled) > > BIT ORIENTED OPERATION (SDLC etc.) > ---------------------------------- > > For operation in SDLC or other bit oriented protocols the DEC MODE bit in > PACSR must be reset. This allows bit > stuffing (The insertion of a "0" bit after each 5 consecutive "1" bits in a data > stream of more than 5 consecutive "1" > bits) to prevent confusing data with FLAG and ABORT sequences. > > The DEC MODE bit being reset also alters the CRC computation so that the > CRC conforms to CRC/CCITT format. Some > protocols may compute the CRC differently and if one of those is in use the > CRC will be disabled using bit 09 of PARCSR. > If CRC is disabled the program must compute any required CRC for the > protocol in use. > > > NOTE > > The following discussion assumes that all required "handshaking" > with the modem has been > completed and the DUP11 has been initialized. > > > > To start transmission, the SEND bit must be set in TXCSR and the TSOM bit > in TXDBUF. This will cause an initial FLAG > character to be transmitted. FLAGs will continue to be transmitted until the > TSOM bit is reset. The transmission of FLAG > characters in this mode is automatic and the characters do not have to be > loaded into the TXDBUF by the processor. When > the TSOM bit is reset, the TXDONE bit will be asserted at the conclusion of > the character in transmission. > > COMM IOP-DUP Page 1-11 > DUP11 > > > When the program "sees" TXDONE, it will start transferring data to the > TXDBUF. At each assertion of TXDONE, another > character of data will be loaded. The CRC computation (if enabled) starts > with the transfer of the first data to TXDBUF. > The transmitter also enters the "transparent" state (bit stuffing is enabled) > when the transmitter starts sending data. > > At the conclusion of the message the program sets the TEOM bit in > TXDBUF and, at the end of the character being > serialized, (if CRC is enabled) the CRC character is transmitted. At the > conclusion of the CRC character a FLAG character > is automatically transmitted. > > The program has three options at this point: SEND may be cleared, which > allows the FLAG character to be completed > and after a delay of 1 1/2 bit times the transmitter enters the IDLE state. > TEOM may be held set, which will cause > continuous FLAG characters to be transmitted. TEOM may be cleared and a > second data message started without setting TSOM. > > The receiver section operates differently for byte oriented and bit > oriented protocols and the two modes are > discussed separately in the following section. > > BYTE ORIENTED RECEIVER (DDCMP, BISYNC etc.) > ------------------------------------------- > > > For BYTE mode operation, the DEC MODE bit and the SYNC character to be > used must be loaded into the PACSR prior to > enabling the receiver. The DEC MODE bit causes the low byte of PACSR to > be recognized as a SYNC character, and the CRC > circuitry of both the receiver and transmitter to use CRC-16 for generating > and checking CRC. > > The STRIP SYNC bit of RXCSR may also be set, which allows SYNC > characters occuring after receiver synchronization to > be automatically deleted. Synchronization is considered complete when 2 > succesive characters which match the low byte of > PACSR have been recognized. The STRIP SYNC bit causes any other leading > SYNC characters to be ignored. > > After the initialization and any needed modem handshaking has been > done, the RCVEN bit in RXCSR may be set. This > enables the receiver to search the incoming signals until 2 successive SYNC > characters are detected. All characters > following the detection of the 2 successive SYNC characters are interpreted > as data. (Unless the STRIP SYNC bit is set, > when it is the detection of the first non-SYNC character that will cause all > following characters to be interpreted as > data.) When this has occured, the RXACT bit will be asserted and the RXDONE > bit set. (Also this will disable the STRIP > SYNC logic until the receiver logic is reinitialized.) > > All data following the SYNC characters is included in the CRC calculation. > For some protocols in the BISYNC family > the CRC logic must be disabled due to possible control characters in the data > field. > > Once RXDONE is set the program will read the assembled character in the > RXBUF, reseting RXDONE. This process will > repeat until the expected number of characters has been received. The > program will then sample the CRC PAR ERR bit to > determine if there was an error in the data received. (If CRC was enabled) > After the CRC is sampled, the RCVEN bit will > be cleared to reinitialize the receiver. > > At this point the entire process may repeat to receive another message. > > BIT MODE RECEIVE OPERATION (SDLC etc.) > -------------------------------------- > > > For SDLC family protocols the DEC MODE bit must be reset. This changes > the CRC checking to CRC/CCITT and enables the > "stuffed" "0" bits in the data stream to be stripped out, restoring the > original data. The "0" bits were originally > inserted to avoid confusion of data with FLAG or ABORT characters. These > characters are detected by the DUP11 when the > DEC MODE bit is not set. > > COMM IOP-DUP Page 1-12 > DUP11 > > > The reset DEC MODE bit also causes a different function to be assigned to > the low byte of PACSR. This byte may be > used as a secondary station address for protocols supporting this option. This > is under the control of bit 12 of PACSR. > > After initialization and any necessary handshaking with the modem, the > RCVEN bit is set. After this bit is set, the > receiver searches the incoming data for FLAG characters. If the receiver is > operating in the primary mode, all data > subsequent to the last initial FLAG character is presented to the program. > The RSOM bit is set with the reception of the > initial data character and RXDONE is set when the data is in the RXDBUF. > > If the receiver is in the secondary address mode, the character > immediately following the last initial FLAG is > compared with the low byte of PACSR. If the character matches the > contents of that byte, the character immediately > following is taken as the start of the data field and TSOM is set. If the > contents do not match, the receiver resumes > looking for FLAG characters and TSOM is not set. > > When the start of the data field is detected, RXACT is set in RXCSR. The > data continues to be assembled (with any > "stuffed" zeros removed) and transferred to the RXDBUF with each transfer > setting RXDONE. The program reads the data from > RXDBUF (which resets RXDONE) with each assertion of RXDONE. > > This process continues until the detection of a FLAG character which > signifies the end of the message. The detection > of the FLAG will cause REOM and RXDONE to set. The contents of the > RXDBUF is invalid when REOM is set. > > If CRC checking is enabled, the check will be valid only when REOM is set. > The entire contents of the message > between the FLAG characters is included in the CRC check. > > INTERRUPT OPERATION > -------------------- > > The DUP11 can be operated in two modes; flag mode, and interrupt > mode. > > In flag mode, the DUP11 does not interrupt the processor. The RXCSR and > TXCSR must be interrogated to determine the > state of the respective DONE bits and the modem control or status bits. > The interrogation must occur often enough to > ensure that characters are removed from, or written into, the respective > DBUF without causing data late or overrun > conditions. > > In the interrupt mode, the DUP11 interrupts the processor when either > DONE bit is set and when the modem changes > status. > > There are two discrete types of interrupt which generate different > vector addresses. Receiver and data set > interrupts generate vector adress XX0. Transmitter interrupts generate > vector address XX4. The XX portion of the vector > is switch selectable. > > Whether the DUP11 is in interrupt or flag mode is determined by bits 5 > and 6 of RXCSR and bit 6 of TXCSR. These are > the interrupt enable bits. Bit 5 of RXCSR controls data set interrupts. Bit 6 > of RXCSR and TXCSR control receiver and > transmitter interrupts respectively. When each of these bits are set, the > corresponding interrupt is enabled. > > Receiver and transmitter interrupts are initiated by the RXDONE and > TXDONE bits respectively. If a DONE bit is set > by the DUP11, and the corresponding interrupt is enabled, an interrupt is > gated to the UNIBUS. > > In the 2020 the DUP11 is operated in the flag mode for data > communications. The servicing of the DUP11 registers is > done by the KMC11 which relieves the KS10 CPU of the overhead. In > diagnostics for the DUP11 on the KS10 the DUP11 is > operated in the interrupt mode. > > > > > -- > This communication may not represent my employer's views, > if any, on the matters discussed. > From litt at ieee.org Wed May 29 12:37:29 2013 From: litt at ieee.org (Timothe Litt) Date: Wed, 29 May 2013 12:37:29 -0400 Subject: [Simh] KDP Documentation In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> References: <51A4D32B.60800@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E73157924@REDROOF2.alohasunset.com> Message-ID: <51A62EC9.60404@ieee.org> > I've got a couple of questions for you or anyone else: > 1) The below document mentions the possibility of one or two DUPs > related to a single KMC. What tells the KMC which DUP it is to > exchange data with, and how does it know the DUP's bus address? The KMC is passed the DUP's address by the OS in a base in command. (It must be in the IO page, so the high address bits don't need to be sent.) ; BASEIN: BSEL2/ *400+3 ; BSEL6/ &017770 The OS knows - it probes the unibus or has the first DUP CSR hard-coded (varies withOS). Then when other commands are sent to the KMC, they include the line number. This is used to find the right DUP. The KMC starts polling the DUP when Control-IN sets ENABLE. > 2) You had mentioned previously that the host OS doesn't interact with > the DUP device except for a possible initial device probe testing for > NXM, and then writing zeros to the registers. What would happen if the > OS didn't find/see the DUP at all? The OS checks for the DUP, and disables the line if it's not present (NXMs). TOPS-20 writes zeros to the registers for some reason - probably paranoia. I have a vague memory that modem status may be looked-at as well, but haven't tracked it down. > 3) How many KMC/DUP devices would work on a given Unibus if there were > no power limitations (i.e. how many devices could the OS software > interact with)? TOPS-20 is hard-coded at 1 KDP with 1 or 2 lines. Expanding the number of lines would be easy; another KDP would be hard. TOPS-10 is coded for more, but the configuration utility has limited it. This would be a trivial patch - note that TOPS-10 monitors are compiled for each system. The limits would be the line number field in the KDP commands, and Unibus mapping resources - each DUP takes at least 1 page - depends on the configured max message size. UBA's are limited to 64 pages (each, but the KDP is known to be on UBA3). But every DMA device uses some. TOPS-10 also supports the DMR (up to 8) - which would be a better way to expand. With two lines, typically a -10 or -20 would use one for DECnet - talking to a router. The other for another protocol; ANF-10, IBM comm. Both happily used gateways to other networks hosted on VAX or 11s, or KLs. Though we tried to use cheap 16/32-bit machines for the grunt work of pushing bits around. > 4) Was there software support for talking to a bare DUP without a > related KMC in any PDP10 operating systems? > Not any DEC OS. Can't speak for ITS, but I doubt it. > 5) Was this KMC/DUP combination ever a supported device on PDP11 or > VAX systems? Thanks. - Mark I don't have a reference handy, but I think it was supported at least on VAX and 11M. They could have a mixture of stand-alone DUPs and DUPs controlled by KMCs. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From Jason.Armistead at otis.com Thu May 30 14:58:54 2013 From: Jason.Armistead at otis.com (Armistead, Jason) Date: Thu, 30 May 2013 18:58:54 +0000 Subject: [Simh] What does "DUP" stand for ? Message-ID: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu May 30 15:12:34 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Thu, 30 May 2013 12:12:34 -0700 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> The recent discussions about KMC11 and DUP11 are about specific devices which existed in the past and were used to provide link layer connectivity for host communicating via DECnet. This has absolutely nothing to do with the SET HOST /DUP. From what I recall, the /DUP in this usage stands/stood for "Diagnostic Utility Protocol)". This is the sum totol of my knowledge on this subject though. The VMS Help says: SET HOST /DUP Connects your terminal to a storage controller through the appropriate bus for that controller. The /SERVER and /TASK qualifiers are required. For use only with storage controllers. Requires the DIAGNOSE privilege. Format SET HOST/DUP/SERVER=server-name /TASK=task-name node-name Additional information available: Parameter Qualifiers /LOG /SERVER /TASK Example From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason Sent: Thursday, May 30, 2013 11:59 AM To: simh at trailing-edge.com Subject: [Simh] What does "DUP" stand for ? There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Thu May 30 15:14:07 2013 From: bqt at softjar.se (Johnny Billquist) Date: Thu, 30 May 2013 21:14:07 +0200 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <51A7A4FF.8050704@softjar.se> On 2013-05-30 20:58, Armistead, Jason wrote: > There’s been a lot of discussion regarding KMC11 and DUP lately. > Can someone remind me what the acronym DUP stands for ? I’ve done a SET > HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but > that was so long ago and I’m a bit rusty. That is a different DUP. :-) Your DUP stands for Diagnostics Utility Protocol, or something like that. The DUP-11 is a synchronous serial interface. A piece of hardware. Johnny From tshoppa at wmata.com Thu May 30 15:18:14 2013 From: tshoppa at wmata.com (Shoppa, Tim) Date: Thu, 30 May 2013 19:18:14 +0000 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> Message-ID: <303A17BD5F8FA34DA45EEC245271AC0B74397247@JGEX2K10MBX2.wmata.local> In SET HOST/DUP/DSSI, DUP expands to "Device Utility Program". I think the is the same expansion and in the same spirit as for RT-11 DUP although of course RT-11 DUP worked with a many different generations of devices older than DSSI. In the communications context, DUP-11 refers to the DUP-11 synchronous interface board. From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Armistead, Jason Sent: Thursday, May 30, 2013 2:59 PM To: simh at trailing-edge.com Subject: [Simh] What does "DUP" stand for ? There's been a lot of discussion regarding KMC11 and DUP lately. Can someone remind me what the acronym DUP stands for ? I've done a SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, but that was so long ago and I'm a bit rusty. Cheers Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From litt at ieee.org Thu May 30 15:21:13 2013 From: litt at ieee.org (Timothe Litt) Date: Thu, 30 May 2013 15:21:13 -0400 Subject: [Simh] What does "DUP" stand for ? In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> References: <78CD6B448AA1E54FBAB5EF46F90F9B382065A309@UUSNWE1S.na.utcmail.com> <0CC6789C1C831B4C8CCFF49D45D7010F9E73157941@REDROOF2.alohasunset.com> Message-ID: <51A7A6A9.7020606@ieee.org> DUP-11 is a comm device - sync line controller. The DUP protocol is part of the packet-based mass storage protocols used by CI (e.g. HSC), DSSI, and UQSSP controllers. Yes, it's Diagnostic Utility Protocol. It's used for configuring, monitoring and running diagnostics on the embedded microcontroller (often a PDP-11 or VAX) that runs a storage controller. This communication may not represent my employer's views, if any, on the matters discussed. On 30-May-13 15:12, Mark Pizzolato - Info Comm wrote: > > The recent discussions about KMC11 and DUP11 are about specific > devices which existed in the past and were used to provide link layer > connectivity for host communicating via DECnet. > > This has absolutely nothing to do with the SET HOST /DUP. From what I > recall, the /DUP in this usage stands/stood for "Diagnostic Utility > Protocol)". This is the sum totol of my knowledge on this subject > though. The VMS Help says: > > SET > > HOST > > /DUP > > Connects your terminal to a storage controller through the > > appropriate bus for that controller. The /SERVER and /TASK > > qualifiers are required. > > For use only with storage controllers. Requires the DIAGNOSE > > privilege. > > Format > > SET HOST/DUP/SERVER=server-name > > /TASK=task-name node-name > > Additional information available: > > Parameter Qualifiers > > /LOG /SERVER /TASK > > Example > > *From:*simh-bounces at trailing-edge.com > [mailto:simh-bounces at trailing-edge.com] *On Behalf Of *Armistead, Jason > *Sent:* Thursday, May 30, 2013 11:59 AM > *To:* simh at trailing-edge.com > *Subject:* [Simh] What does "DUP" stand for ? > > There's been a lot of discussion regarding KMC11 and DUP lately. > > Can someone remind me what the acronym DUP stands for ? I've done a > SET HOST /DUP /DSSI before on a VAX4000-300 to set up the DSSI disks, > but that was so long ago and I'm a bit rusty. > > Cheers > > Jason > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From dave_list_addr at verizon.net Thu May 30 18:48:29 2013 From: dave_list_addr at verizon.net (dave porter) Date: Thu, 30 May 2013 18:48:29 -0400 Subject: [Simh] Simh Digest, Vol 113, Issue 24 In-Reply-To: References: Message-ID: <24E85722F40B4AD3BCFF2970701E59BC@street> > What does DUP stand for? Mostly it stands for the fact that all the good 2-character communication device names were already taken. In particular we already had a DU11 and a DP11 ... I think the DUP11 might have been a replacement for the DP11 (not in any 'compatible' sense), but since my 1976 Peripherals Handbook has gone missing, I can't be too sure. dave From aek at bitsavers.org Thu May 30 19:02:47 2013 From: aek at bitsavers.org (Al Kossow) Date: Thu, 30 May 2013 16:02:47 -0700 Subject: [Simh] Simh Digest, Vol 113, Issue 24 In-Reply-To: <24E85722F40B4AD3BCFF2970701E59BC@street> References: <24E85722F40B4AD3BCFF2970701E59BC@street> Message-ID: <51A7DA97.1010804@bitsavers.org> On 5/30/13 3:48 PM, dave porter wrote: > my 1976 Peripherals Handbook has gone missing 72, 73 and 76 are on line under http://bitsavers.org/pdf/dec/pdp11/handbooks From Mark at infocomm.com Fri May 31 12:38:57 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 31 May 2013 09:38:57 -0700 Subject: [Simh] card reader and running commands References: <063d01ce4b72$eb14d8d0$c13e8a70$@ntlworld.com> <034b01ce5486$06b04810$1410d830$@ntlworld.com> <5198D982.80809@ieee.org> <035801ce549c$0d6c3630$2844a290$@ntlworld.com> <036601ce54a1$c1719f80$4454de80$@ntlworld.com> <5198F73E.803@ieee.org> <037901ce54af$0b17c440$21474cc0$@ntlworld.com> <5199054D.2030909@ieee.org> <03b501ce54cc$52e31b40$f8a951c0$@ntlworld.com> <519938D9.1010209@ieee.org> <03ce01ce54da$5c53c2c0$14fb4840$@ntlworld.com> <039001ce59e8$4a97cc30$dfc76490$@ntlworld.com> <51A1E311.4040109@ieee.org> <044b01ce5abf$536ae1d0$fa40a570$@ntlworld.com> <51A35021.40300@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578C6@REDROOF2.alohasunset.com> <51A3565E.1050108@ieee.org> <51A35D0E.8050501@ieee.org> <51A369D3.4070402@jordi.guillaumes.name> <51A37443.8070002@ieee.org> <51A37FED.4010702@jordi.guillaumes.name> <51A38540.9050903@ieee. org> <51A3B2E C.70305@ieee.org> <0CC6789C1C831B4C8CCFF49D45D7010F9E731578D7@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F9E7315795F@REDROOF2.alohasunset.com> On Monday, May 27, 2013 at 1:25 PM, Mark Pizzolato wrote: > On Monday, May 27, 2013 at 1:12 PM, Jordi wrote: > > El 27/05/2013, a les 21:36, Mark Pizzolato - Info Comm > > va escriure: > > > > > The Remote Console Facility allows a TELNET Connection to a user > > designated port so that some out of band commands can be entered to > > manipulate and/or adjust a running simulator. The commands which > > enable and control this capability are SET REMOTE TELNET=port, SET > > REMOTE CONNECTIONS=n, SET REMOTE TIMEOUT=seconds, and SHOW > REMOTE. > > > > Hi Mark, > > > > The remote console addition is really useful! (It would justify > > upgrading simh to 4.0 by itself, in my opinion). I, however, have a > > suggestion: could you add a command to disconnect the telnet session? > > Right now the only way is to break into TELNET command mode and CLOSE > the connection there... > > Hmmm... You have to do the same thing to disconnect from any console > session.... This seems easy enough... Well, after further thought. I've changed the remote console to exit the current remote console session when an EOF character is received (i.e. either ^D or ^Z). - Mark