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

Robert Jarratt robert.jarratt at ntlworld.com
Sun May 19 16:06:15 EDT 2013 

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,<<T1,D>,<T2,D>>) << 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
> > >>>>> <http://bitsavers.trailing-
> > >>>>> 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" <robert.jarratt at ntlworld.com>
> > >>>>>>>>>> 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
> >

More information about the Simh mailing list