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

Timothe Litt litt at ieee.org
Sun May 19 13:01:01 EDT 2013 

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130519/da5dd95b/attachment-0002.bin>

More information about the Simh mailing list