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