[Simh] TOPS-20 Source with KMC11 Driver Code?
Timothe Litt
litt at ieee.org
Mon May 27 08:22:57 EDT 2013
Inline.
This communication may not represent my employer's views,
if any, on the matters discussed.
On 27-May-13 05:48, Robert Jarratt wrote:
>
>> -----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
You must be the first user of these routines...
Map_WriteB() isn't clearing the 4 MBZ bits either.
M[pa10] = (M[pa10] & ~(mask << ubashf[ba & 3])) |
(((d10) *buf++) << ubashf[ba & 3];
should be:
M[pa10] = ((M[pa10] & ~(mask << ubashf[ba & 3])) |
(((d10) *buf++) << ubashf[ba & 3]) & ~INT64_C(0600000600000));
Looks like Map_WriteW() cloned it. Ideally, Map_WriteW() should take a
(16-bit) word count rather than a byte count.
That would simplify life for the code and callers alike. But the VAX
UBA routines have the same prototype, so I guess we're stuck with it.
A more correct fix would be something like the following (but they still
should only check the map on page boundaries, which I'm too lazy to code
right now). I haven't compiled this, but I think the logic is correct.
# Here we optionally allow return of the map entry
a10 Map_Addr10 (a10 ba, int32 ub, int32 *ubm)
{
a10 pa10;
int32 vpn = PAG_GETVPN (ba >> 2); /* get PDP-10 page number */
if ((vpn >= UMAP_MEMSIZE) || (ba & XBA_MBZ) || /* invalid map? */
((ubmap[ub][vpn] & UMAP_VLD) == 0))
return -1;
pa10 = (ubmap[ub][vpn] + PAG_GETOFF (ba >> 2)) & PAMASK;
if (ubm)
*ubm = ubmap[ub][vpn]; /* Return map entry if requested */
return pa10;
}
/* The next 5 routines would be more efficient if they only called
Map_Addr10 for the first transfer & when crossing a page. */
# pass NULL to Map_addr10. No other changes.
int32 Map_ReadB (uint32 ba, int32 bc, uint8 *buf)
...
pa10 = Map_Addr10 (ba, 1, NULL);
...
int32 Map_ReadW (uint32 ba, int32 bc, uint8 *buf)
...
pa10 = Map_Addr10 (ba, 1, NULL);
...
#replace existing routines - these should correctly handle UB<17:16>
/* Byte-mode writes */
int32 Map_WriteB (uint32 ba, int32 bc, uint8 *buf)
{
uint32 lim;
a10 pa10;
d10 mask;
lim = ba + bc;
for ( ; ba < lim; ba++) { /* by bytes */
pa10 = Map_Addr10 (ba, 1, NULL); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
if( (ba&3) == 0 ) { /* byte 0 writes memory; other bytes &
<0:1,18:19> of M[] are undefined. */
M[pa10] = ((d10) *buf++) << 18; /* Clears undefined bits */
} else { /* RPW - clear byte position, and UB<17:16> of correct 1/2
word when writing high byte */
mask = 0377<< ubashf[ba & 3];
if (ba & 1)
mask |= INT64_C(0000000600000) << ((ba & 2)? 0 : 18);
M[pa10] = (M[pa10] & ~mask) |
(((d10) *buf++) << ubashf[ba & 3]);
}
}
return 0;
}
/* Word mode writes; 16-bit data */
int32 Map_WriteW (uint32 ba, int32 bc, uint16 *buf)
{
uint32 lim;
uint32 ubm;
a10 pa10;
d10 val;
ba = ba & ~01; /* align start */
lim = ba + (bc & ~01);
for ( ; ba < lim; ba+= 2) { /* by words */
pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
val = *buf++; /* get 16-bit data, clearing <17:16> */
if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
} else {
if (ba & 2) /* Write odd preserves even word */
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = val << 18; /* Write even clears odd *
}
return 0;
}
# new (unused) routine for 18-bit devices. Identical, except input is
18 bits (in 32 bits).
/* Word mode writes; 18-bit data */
int32 Map_WriteW18 (uint32 ba, int32 bc, uint32 *buf)
{
uint32 lim;
uint32 ubm;
a10 pa10;
d10 val;
ba = ba & ~01; /* align start */
lim = ba + (bc & ~01);
for ( ; ba < lim; ba+= 2) { /* by words */
pa10 = Map_Addr10 (ba, 1, &ubm); /* map addr */
if ((pa10 < 0) || MEM_ADDR_NXM (pa10)) { /* inv map or NXM? */
ubcs[1] = ubcs[1] | UBCS_TMO; /* UBA times out */
return (lim - ba); /* return bc */
}
val = *buf++; /* get 18-bit data */
if (ubm & UMAP_RRV ) { /* Read reverse preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = (M[pa10] & INT64_C(0000000777777)) | (val << 18);
} else { /* Write odd preserves even word */
if (ba & 2)
M[pa10] = (M[pa10] & INT64_C(0777777000000)) | val;
else M[pa10] = val << 18; /* Write even clears odd */
}
return 0;
}
>> 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
>
This I'd need to debug on the -10 side. I suspect it's a JSYS failure.
Wild guess: NETCON isn't running with correct privileges?
>
>> 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....
Probably can take what I supplied above and simply call Map_Addr10
before the for loops, then
update when ba crosses a page boundary. The existing routines should
handle large buffers if you do that.
>
>> 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
-------------- 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/20130527/c690aa2d/attachment-0002.bin>
More information about the Simh
mailing list