[Simh] TOPS-20 Source with KMC11 Driver Code?
Robert Jarratt
robert.jarratt at ntlworld.com
Sun May 19 16:01:04 EDT 2013
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