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

Timothe Litt litt at ieee.org
Sun May 19 16:40:57 EDT 2013 

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,<<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/94169900/attachment-0002.bin>

More information about the Simh mailing list