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

Timothe Litt Sun, 26 May 2013 03:29:10 -0700

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...)


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.

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?

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...

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: [email protected] [mailto:simh-bounces@trailing-
edge.com] On Behalf Of Robert Jarratt
Sent: 19 May 2013 22:47
To: 'Timothe Litt'
Cc: [email protected]
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:[email protected]]
Sent: 19 May 2013 21:41
To: Robert Jarratt
Cc: [email protected]
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:[email protected]]
Sent: 19 May 2013 21:01
To: 'Timothe Litt'; '[email protected]'
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: [email protected]
[mailto:simh-bounces@trailing- edge.com] On Behalf Of Timothe Litt
Sent: 19 May 2013 18:01
To: [email protected]
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: [email protected] [mailto:simh-

bounces@trailing-

edge.com] On Behalf Of Timothe Litt
Sent: 19 May 2013 17:01
Cc: [email protected]
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,

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: [email protected] [mailto:simh-

bounces@trailing-

edge.com] On Behalf Of Robert Jarratt
Sent: 19 May 2013 15:21
To: 'Timothe Litt'; [email protected]
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

much

older version of SIMH.

Regards

Rob

-----Original Message-----
From: [email protected]
[mailto:simh-bounces@trailing- edge.com] On Behalf Of

Timothe

Litt
Sent: 19 May 2013 14:54
To: [email protected]
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: [email protected] [mailto:simh-

bounces@trailing-

edge.com] On Behalf Of Timothe Litt
Sent: 19 May 2013 11:26
To: [email protected]
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: [email protected] [mailto:simh-

bounces@trailing-

edge.com] On Behalf Of Rich Alderson
Sent: 08 May 2013 01:02
To: [email protected]; [email protected]
Subject: Re: [Simh] TOPS-20 Source with KMC11 Driver

Code?

From: "Robert Jarratt" <[email protected]>
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
[email protected]
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
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh


_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

Reply via email to