[Simh] TOPS-20 Source with KMC11 Driver Code?
Robert Jarratt
robert.jarratt at ntlworld.com
Mon May 27 05:48:19 EDT 2013
> -----Original Message-----
> From: Timothe Litt [mailto:litt at ieee.org]
> Sent: 26 May 2013 11:25
> To: Robert Jarratt
> Cc: simh at trailing-edge.com
> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code?
>
> Rob,
>
> Thanks for the log. Looks like both simh and you have some bugs. But
> you're close to working...
>
> First nit: the KMC CMD & DUP QUEUE debug messaged looks like they are
> trying to print hex as well as octal - missing a % in the printf()
> format? (Assuming the data is passed twice...)
Oops! Missed that, thanks.
>
> The descriptors look reasonable.
>
> Second: The Map_WriteW routine (in pdp10_ksio.c) is preserving bits 0,1,
> 18 & 19, but this is a 16-bit device. The real UBA would clear them in
> this case. This is a bug in simh.
Changing ksio from this
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777600000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0600000777777)) | (val << 18);
To this
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
Seemed to cure the immediate problem
>
> TOPS-20's KDPSRV has set the buffer data to -1 (36-bits) before queuing
> the buffer to the KMC. The BUGCHK is complaining that bit 0 is set when
> the buffer is received. This is a paranoia check to see if the KMC is
> returning a buffer that it didn't write to.
>
> Also, the real UBA wouldn't do a read-modify-write on the first 16-bit
> write (unless read-reverse was set in the UBA map entry). It would
> simply write the first word. The odd word is also done as a simple
> write because the UBA saves the even word's data - that's roughly
> equivalent to RMW. (See
> http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KS10/EK-OKS10-TM-
> 002_tech_Sep79.pdf
> around page 5-119 for the gory details, including other transfer modes.)
>
> Third: The additional data in the bugchk is the 10-side view of the
> buffer's first two 36-bit words. This is not the correct data. Note
> that 3 16-bit words are written, which corresponds to your 6 bytes. But
> the data is the same (0746314) in each word. The unwritten word is
> 0777777, which is a good sign that the mapping is correct (though not
> what a real UBA would do). If we clear the two high bits of the data,
> we get 0146314, which is 0xCCcc.
>
> 0xcc happens to be the low byte of the last DMA UB WRITE's address.
> Perhaps the address and data arguments to your unibus_write routine are
> swapped?
This bit had me stumped until I really checked what was going on in
Map_WriteW. I think there is a bug in it on this line:
for ( ; ba < lim; ba++) { /* by bytes */
It should be
for ( ; ba < lim; ba += 2) { /* by bytes */
That is why 0xCCCC was getting written to the memory. Now I can see that the
right data gets into the OS because I temporarily provoked the bugchk again
by not clearing the bits, the additional data looked correct this time.
However, I still see one end repeatedly sending the first DDCMP message (05
06 C0 00 00 01), but nothing else happens, no response going the other way,
no messages on the console etc. I notice that I do get this message on
bootup though:
SJ 3: $RUN SYS:NETCON
SJ 2: ?ILLEGAL INSTRUCTION 0 AT 236246
SJ 2: ?UNDEFINED OPERATION CODE
SJ 3:
SJ 3: % NETCON: COULD NOT OBTAIN NETWORK TOPOLOGY
Could it be that I still don't have the right version of DECnet on this
virtual machine?
Thanks!
Rob
>
> You might want to look at pdp10_tu.c for a more efficient way of doing
> large unibus transfers. It (FNC_READF and FNC_WRITE) does the expensive
> unibus mapping only once per page, and writes directly to -10 memory -
> bypassing the bug in Map_WriteW. It also handles NXM reporting, which
> hopefully the caller to your interface code is doing...
It looks like rather than patch Map_WriteW above it would be better to write
a couple of general DMA routines for transferring large buffers. I will try
to do that, let's see if I understand everything you and Rob Doyle have
said....
>
> Note, though, that the tu works thru a RH11, which is an 18-bit device
> and the tape is packing bytes into 36-bit words in odd ways. Don't let
> that confuse you.
>
> Yes, KDPSRV will always return the same buffers; that's expected. It has
> statically allocated buffers for each line's transmit and receive and
> copies data in and out. This is partly due to byte re-ordering and
> partly a matter of simplifying UBA mapping register management.
>
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
> On 26-May-13 04:09, Robert Jarratt wrote:
> > Tim,
> >
> > I have been looking very closely at how I am writing to the memory and I
> > cannot see anything obviously wrong. Let me run you through one receive
> > buffer transfer with some extracts from the log, see if you can spot any
> > flaws:
> >
> > On startup I get two receive buffers as follows:
> >
> > DBG(285632654)> KMC CMD: Input command: sel2=000004 sel4=111710
> sel6=020000
> > DBG(285632654)> KMC CMD: Line 0 ba=0x93c8(111710 octal)
> > DBG(285632654)> KMC CMD: Descriptor for rx buffer:
> > DBG(285632654)> KMC CMD: Word 1 = 0x04X(111730 octal)
> > DBG(285632654)> KMC CMD: Word 2 = 0x04X(000600 octal)
> > DBG(285632654)> KMC CMD: Word 3 = 0x04X(100000 octal)
> > DBG(285632654)> DUP0 QUEUE: Queued rx buffer 0, descriptor
> > address=0x93C8(111710 octal)
> >
> > DBG(285632752)> KMC CMD: Input command: sel2=000004 sel4=112530
> sel6=020000
> > DBG(285632752)> KMC CMD: Line 0 ba=0x9558(112530 octal)
> > DBG(285632752)> KMC CMD: Descriptor for rx buffer:
> > DBG(285632752)> KMC CMD: Word 1 = 0x04X(112550 octal)
> > DBG(285632752)> KMC CMD: Word 2 = 0x04X(000600 octal)
> > DBG(285632752)> KMC CMD: Word 3 = 0x04X(100000 octal)
> > DBG(285632752)> DUP0 QUEUE: Queued rx buffer 1, descriptor
> > address=0x9558(112530 octal)
> >
> > A little while later I receive the 6 bytes of data from the peer:
> >
> > DBG(582050921)> DUP0 DATA: Read packet, length 6: 05 06 C0 00 00 01
> > DBG(582050921)> DUP0 QUEUE: dup_receive ba=0x93c8(111710 octal).
> Descriptor
> > is:
> > DBG(582050921)> DUP0 QUEUE: Word 1 = 0x04X(111730 octal)
> > DBG(582050921)> DUP0 QUEUE: Word 2 = 0x04X(000600 octal)
> > DBG(582050921)> DUP0 QUEUE: Word 3 = 0x04X(100000 octal)
> > DBG(582050921)> DUP0 QUEUE: Receive buf[0] writing to
> address=0x93D8(111730
> > octal), bytes=6
> > dma ub write 0x000093d8=003005(oct)
> > dma ub write 0x000093da=000300(oct)
> > dma ub write 0x000093dc=000400(oct)
> > dma ub write 0x000093cc=101400(oct)
> >
> > So the memory appears to get written correctly to the correct location.
I
> > then transfer the buffer out to the OS using an output command (no
> detailed
> > trace for that), this is immediately followed by me receiving a new
receive
> > buffer (the very one I just sent, so I think the output transfer must
have
> > worked) and the error from the OS:
> >
> > DBG(582051478)> KMC CMD: Input command: sel2=000004 sel4=111710
> sel6=020000
> > DBG(582051478)> KMC CMD: Line 0 ba=0x93c8(111710 octal)
> > DBG(582051478)> KMC CMD: Descriptor for rx buffer:
> > DBG(582051478)> KMC CMD: Word 1 = 0x04X(111730 octal)
> > DBG(582051478)> KMC CMD: Word 2 = 0x04X(000600 octal)
> > DBG(582051478)> KMC CMD: Word 3 = 0x04X(100000 octal)
> > DBG(582051478)> DUP0 QUEUE: Queued rx buffer 1, descriptor
> > address=0x93C8(111710 octal)
> >
> > ********************
> > *BUGCHK "BADHDR" AT 26-MAY-2013 08:46:24
> > *BAD DDCMP HEADER
> > *ADDITIONAL DATA: 746314746314, 746314777777
> > ********************
> >
> > My suspicion fell on the code to write the data to the memory, this is
the
> > unibus_write code:
> >
> > extern t_stat unibus_write(int32 data, int32 addr)
> > {
> > uint16 d;
> >
> > d = data & 0xFFFF;
> >
> > return Map_WriteW (addr, 2, &d);
> > }
> >
> > Which looks OK to me.
> >
> > 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 22:47
> >> To: 'Timothe Litt'
> >> Cc: simh at trailing-edge.com
> >> Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver Code?
> >>
> >> 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
> >>
> >> _______________________________________________
> >> Simh mailing list
> >> Simh at trailing-edge.com
> >> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
More information about the Simh
mailing list